@kall32 Da zweifle ich mal kurz das Prinzip an ;) Das hört sich für mich an, als würde man das Pferd verkehrt herum aufzäunen.
pfSense steht am nähesten am Internet, es macht also Sinn, wenn die Sense Upstream ist bspw. für die PiHole(s). Somit würde es dann aber keinen Sinn machen, die Sense als DNS rauszurollen und dort dann die PiHoles als Upstream anzugeben, nur damit die wieder irgendwas im Internet als Forwarder haben, da die PiHoles kein Resolving per default machen.
Sinnvoller wäre da für mich:
PiHole(s) als Default DNS per DHCP rausgeben
Intern Regeln, dass DNS erlaubt wird auf die PiHole IP(s)
alles was intern DNS spricht auf PiHoles umleiten wenn was externes aufgerufen werden soll (redirect)
In PiHoles pfSense als Upstream reinmachen
pfSense Unbound im Resolver Mode laufen lassen
in pfSense Regeln anlegen, dass intern nichts direkt gegen die Sense DNS machen darf (direkt an unbound) sondern alles via PiHole gefiltert wird
Dann wird Unbound sinnvoll genutzt mit DNSsec und Resolving (und nicht forwarding zu irgendeinem Datensammler) und intern wird durch PiHole aber ordentlich DNS gefiltert und kann über deren Admin UI sauber administriert werden.
Hab ich mit 2x Pis und Gravity hier zu Hause schon ewig so laufen und das brummt gut. Für Update/Redundanz einfach 2 PiHole Instanzen aufsetzen, 2. Instanz via Gravity an 1. Instanz dranhängen, dann muss man Blocklisten und Ausnahmen nur auf einer Instanz verwalten und hat trotzdem nen 2. PiHole als DNS zum Eintragen, dass es nen Fallback gibt.
Zusätzlich kann man ggf. noch ausgehend Port 853 (DoT) aus den internen Netzen verbieten und 443 auf bekannte DoH Server verbieten, damit irgendwelche internen Kisten den PiHole nicht "überspringen" können. (oder zumindest nicht so einfach).
Cheers