Unbound VS gravity-sync

dnsmasq and unbound are impacted to

https://github.com/NLnetLabs/unbound/releases/tag/release-1....

https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/20...

As are any other DNSSEC validators that followed the specifications.

Bind9 has its problems but this is not its fault this time.

Are you familiar with https://pi-hole.net/ ?

In my house I want DNS resolution to be performed by my own DNS resolver (https://github.com/NLnetLabs/unbound), after I block ad domains.

DoH circumvents that.

So yep it's an unbound thing: https://github.com/NLnetLabs/unbound/issues/438 there was a PR to allow a user to change the depth of a chase. I doubt F5 would have that version of unbound in any current software but support may be able to check or look at a lab 17.1 to see what version it is--you could then manually edit the conf file but it wouldn't persist through upgrades..

That's confirms in issue#362 I found.

The last time I checked, Unbound does not support upstream DoH. You can configure it to reply to DoH requests from clients, but you can't use it to forward queries to another DoH provider like Cloudflare or Quad9. Has that changed? The pull request has been open for 3 years.

And, while the documentation for unbound.conf doesn’t say a whole lot about the iterator module specifically as far as I can tell, the code says:

Gravity-Sync won't do that. But searching around on GH, I found this : https://github.com/NLnetLabs/unbound/blob/master/contrib/unbound_cache.sh

Version 1.15.0 Configure line: --with-libexpat=/usr/local --with-ssl=/usr --disable-dnscrypt --disable-dnstap --with-libnghttp2 --enable-ecdsa --disable-event-api --enable-gost --with-libevent --with-pythonmodule=yes --with-pyunbound=yes ac_cv_path_SWIG=/usr/local/bin/swig LDFLAGS=-L/usr/local/lib --disable-subnet --disable-tfo-client --disable-tfo-server --with-pthreads --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/share/info/ --build=amd64-portbld-freebsd12.3 Linked libs: libevent 2.1.12-stable (it uses kqueue), OpenSSL 1.1.1n-freebsd 15 Mar 2022 Linked modules: dns64 python respip validator iterator BSD licensed, see LICENSE in source package for details. Report bugs to [email protected] or https://github.com/NLnetLabs/unbound/issues

"Unbound" for example https://github.com/NLnetLabs/unbound

OR I could implement https://github.com/vmstan/gravity-sync as it's last commit was a year ago but users still seem to be using it.

I run the split DHCP approach for years without issues. Having only one PiHole with DHCP Server doesn’t give you a fully redundant system. I don’t use Gravity Sync myself, but their wiki covers this case with examples: https://github.com/vmstan/gravity-sync/wiki/DHCP-Replication

the github page has a really good walkthrough and explanation

I don't have anything add to your question. But I recommend installing gravity-sync if you're going to run two piholes. It will sync up DNS entries (among other things) automatically to the second pihole when you add a entry one of them. https://github.com/vmstan/gravity-sync

If you go the 2 pihole route, I strongly recommend Gravity-Synch. https://github.com/vmstan/gravity-sync

Run Pihole on both, if DNS goes down its painful. You can sync them with https://github.com/vmstan/gravity-sync