Omdat jij bij de DHCP server als DNS server 10.0.0.30 hebt opgegeven zullen de IPv4 cliënts dat IP adres als DNS server gebruiken dus dat is prima. Als het goed is zie je die 10.0.0.30 dan ook terug als DNS server op een aangesloten computer.

De DNS forwarder wordt alleen gebruikt als je bij de DHCP server de router (10.0.0.1) als DNS server zou opgeven.

Het heeft overigens geen zin om eth0.6 als interface in de forwarder op te nemen.

Dank voor de tip en uitleg. Ik heb DNS forwarding verwijderd en alles werkt inderdaad nog zoals jij voorspelde.

Mag ik nog een vraag stellen @wjb? Zo ja, wat is nu de WAN in mijn situatie: eth0.6, of eth0, of pppoe0?

Jouw WAN is de pppoe0.

Ik zag dat er nog steeds devices rechtstreeks naar een DNS server (bijv een Chromecast naar 8.8.8.8) ipv de Pi-hole. Onderstaande config vangt alle dns queries af die van andere devices komen dan de dns servers op eth1 en stuurt deze door naar de Pi-holes. Voor het request lijkt het net of deze vanaf de gevraagde dns komt, maar wordt gemaskeerd en komt vanaf de Pi-hole.

Ik heb dit ook alleen voor eth1 gedaan, aangezien dit het lan is waar dit soort devices in zitten. Mijn iot vlan mag sowieso niet naar internet toe.

Uitleg, Ik heb 4 dns servers (2x domain controller en 2x Pi-hole) op 192.168.0.240-192.168.0.244) en mijn LAN staat op eth1. Pas de ip adressen en de rule nummering aan naar jouw situatie. 

rule 1 {
    description "Captive DNS to Pi-hole"
    destination {
        address !192.168.0.240-192.168.0.244
        port 53
    }
    inbound-interface eth1
    inside-address {
        address 192.168.0.240-192.168.0.244
        port 53
    }
    log disable
    protocol tcp_udp
    source {
        address !192.168.0.240-192.168.0.244
    }
    type destination
}

rule 5001 {
    description "Masquerade for DNS"
    destination {
        address 192.168.0.240-192.168.0.244
        group {
        }
        port 53
    }
    log disable
    outbound-interface eth1
    protocol tcp_udp
    source {
        address 192.168.0.1-192.168.0.254
        group {
        }
    }
    type masquerade
}

PS C:\Users\xxxxxx> nslookup wp.com 195.121.1.34
Server:  ns1.wxs.nl
Address:  195.121.1.34

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
Name:    wp.com
Address:  192.168.0.243

Dank voor je reactie @marcor1 . Ik heb zojuist even gecontroleerd (ik heb slechts 1 pi-hole) en krijg dit als resultaat. Betekent dat ik het niet juist geconfigureerd heb of ontstaat dit doordat ik maar 1 pi-hole gebruik?

Configuratie:

 Output:

C:\Users\#####>nslookup wp.com 195.121.1.34
Server:  ns1.wxs.nl
Address:  195.121.1.34

Name:    wp.com
Addresses:  ::
          0.0.0.0

Ik weet overigens niet wat een domain controller is, maar laat me graag informeren. Het lijkt iets met identiteitscontrole binnen een netwerk te maken te hebben: https://jumpcloud.com/blog/what-is-a-domain-controller

Mijn domain controllers zijn onderdeel van Microsoft Active Directory en is normaal niet iets voor een thuis omgeving. Het hoort in een zakelijke omgeving thuis. Ik heb dan ook niet een gewone thuis situatie. Je linkt geeft aardig weer wat een domain controller is.

De reden waarom ik een Edgerouter 4 gebruik, deze is ook ondersteund vanuit Microsft Azure en verbind deze mbv IPSec tunnels naar mijn thuis omgeving.

Je output lijkt mij goed, indien wp.com ook op je blacklist staat. Ik zie in de Pi-hole documentatie dat de return nu 0.0.0.0 is ipv het ip van de Pi-hole. (en dat mijn setup dus al oud is, nog een item op de to-do lijst.) Er zal nu geen device op je netwerk direct naar een publieke DNS kunnen gaan, maar komt altijd uit op Pi-hole. Kortom je output lijkt me goed.

Ook voor IPv6 zal je dan rules op moeten zetten om te forceren dat DNS requests via jouw Pi-Hole lopen.

Dat klopt, maar ik ben pas net over van Telfort naar KPN en heb IPv6 nog niet geconfigureerd op mijn edgerouter. Hetzelfde moet je idd ook doen voor IPv6. Als ik het werkend heb zal ik de config posten.

Alleen voor/tegen DoH heb ik nog niets gevonden.

@marcor1 wellicht is het volgende document interessant voor je: https://docs.pi-hole.net/guides/dns/cloudflared/

Het artikel verteld hoe je DoH voor je Pi-hole moet configureren. Dit kan je doen zodat je provider niet mee kan kijken naar je requests (KPN doet dat volgens mij niet). Maar als een device op je netwerk DoH gebruikt dan zal de configuratie zoals hierboven dit request niet kunnen zien en dus ook niet tegen kunnen houden.