From my point of view, you're wasting time and resources for a long-term maintenance-intensive redesign of the outdated dnsmasq. Moreover, such integration unnecessarily increases complexity and makes troubleshooting difficult. A clean unbound implementation would be better.
It offers everything you need in small environments - caching, DNSEC and especially QNAME minimization. https://ripe72.ripe.net/presentations/120-unbound_qnamemin_ripe72.pdf
Any DNS forwarding assumes that the DNS service is trustworthy. For which one do you put your hand in the fire? For privacy reasons it is currently no alternative for DNS in conjunction with DNSSEC to use DNS resolvers with QNAME minimization. Don't you learn anything from the various data protection scandals, as recently on Facebook? I use a RaspberryPI with unbound and QNAME minimization as forwarder.
Most of all DNS requests come from the unbound cache in addition to the local pihole cache.
If you don't want to give up dnsmasq completely, at least offer a clean integration of a local unbound-installation next to the dnsmasq, so that at least only a local forwarding has to be done.
Many of us are fans of Unbound. dnsmasq has served our needs well throughout the project. Is there a specific reason you think it is outdated? And what makes it complex to troubleshoot? It's the same dnsmasq we have always used, but its closely coupled to our software, which should make for easier troubleshooting by removing variables from consumers installation.
We have often discussed giving users the choice of what DNS server to install and/or what Web server, but the unfortunate thing it comes down to is time to develop. We're all volunteers working on this in our free time.
As of now, I don't see dnsmasq going away from Pi-hole since we are very familiar with it and we also have some lines of communication with Simon Kelley, which works to our advantage when developing if we run into questions.
That's very honorable, and I appreciate it very much. You are one of the few projects to achieve such high performance in the long run.
So much the worse that you get bogged down.
I don't see how we would get bogged down by integrating with Dnsmasq. Have you looked at how we integrate? We basically just embed dnsmasq in, and call some of our functions when events happen, like when a query is received and answered. This makes it extremely easy to upgrade to the latest dnsmasq version, and the integration actually reduces complexity beause we no longer have to read the log file and guess what dnsmasq was doing.
ok, you're the expert. I didn't mean to discourage you.
I hope, you're going the right way. How do you want to implement QNAME minimization?
Or do you have an alternative solution to protect users from the data wealth of DNS providers?
If it's easy to profile user behavior anywhere, it's on the DNS server.
You've made the assumption that we are looking to implement QNAME minimization. It's not something that you are going to be able to do with 2 upstream DNS servers. For the folks following at home, QNAME minimization is a technique that is a way to obfuscate the target domain name if you're following the chain from . to the final domain. Instead of asking the same DNS server what . is, and then .com. followed by foo.com. and then the final target domain of bar.foo.com., each request goes to a different DNS upstream server. dnsmasq is a stub resolver, and only would trace the chain when DNSSEC is enabled, as it's required in DNSSEC to validate the signatures of every step from ROOT to FQDN.
So far, this is the only topic that mentions QNAME, so the priority of implementing it over other Feature Requests will be obviously low. Switching to a new resolver will just add more complexity when we are trying to reduce complexity. We still would need dnsmasq or a DHCP server, and then integrate that into what ever the new resolver would be. This would bring development to a screeching halt while the entire package and all features were redone for a totally new internal structure.
I know that. I don't use external forwarders. I use an internal unbound resolver at RaspberryPI with QNAME minimization. But I would prefer to have this unbound service on the same machine like Pi-Hole.
I discovered Pi-Hole 2 years ago and it's a bootstrap project who's just works, well from the beginning; no config or tweak needs. I, and will, continue to implement and recommend Pi-Hole.
@MaDa : I also reproduce what pi-hole do with unbound on OPNsense, a fork of pfSense. Nothing stop you to "fork" the project than start a pi-bound or unbhole.
For a little history moment: dnsMASQ is considered one of the most lightweight DNS service which made sense to choose when they start the project in 2015 on raspi 2.