Pi-Hole als AdBlocking Nameserver

Ich hatte vor einiger Zeit schon den Pi-Hole als Docker-Container installiert und den als Forwarder für meinen internen Bind-Nameserver, der auf dem Docker-Host läuft, konfiguriert. Da dann im Log vom Pi-Hole aber immer nur die IP meines internen DNS auftauchte, wollte ich diese Kette umdrehen. Dazu musste ich einige Klippen umschiffen.

1. In Pi-Hole selber kann ich keine Forwarding-DNS-Server mit einem anderen Port angeben! Es geht also nur Port 53.
   Also muss ich meinen Bind auf Port 53 belassen. Daher dachte ich mir, ich lege ein weiteres Interface auf dem Host an, auf dem ich dann den Bind laufen lasse.
   Wenn ich also beispielsweise folgende Netzwerk-Konfiguration habe:

   eth0:  192.168.1.10
   eth0.1: 192.168.1.11

   Dann kann ich Folgendes in der named.conf eintragen: listen-on port 53 { 192.168.1.11; };
   Damit läuft dann Bind nur auf eth0.1.

2. Normalerweise binden sich Docker-Container an alle lokalen Adressen des Hosts. Damit kommt sich Pi-Hole mit dem lokal laufenden Bind in die Quere. Da ich den Pi-Hole aber per docker-compose starte, kann ich die docker-compose.yml wie folgt konfigurieren:

   pihole:
     restart: unless-stopped
     container_name: pihole
     image: diginc/pi-hole:alpine
     volumes:
       - /var/pihole:/etc/pihole
     environment:
       - ServerIP=192.168.1.10
       - DNS1=192.168.1.11
     cap_add:
       - NET_ADMIN
     ports:
       - "192.168.1.10:53:53/tcp"
       - "192.168.1.10:53:53/udp"
       - "8080:80"

   Mit ports: -"192.168.1.10:53:53/tcp -"192.168.1.10:53:53/udp bindet sich der Docker-Container für die DNS-Ports nur auf die IP 192.168.1.10 (eth0) und kommt sich somit nicht mit der IP von eth0.1 in die Quere.

3. Pi-Hole setzt intern auf dnsmasq. Das ist zunächst einmal kein Problem. Bei genauerer Betrachtung aber schon:
   1. Gebe ich keinen zweiten DNS-Server in docker-compose.yml mit, dann setzt Pi-Hole den wohl automatisch auf die Google-Nameserver. Das halte ich persönlich schon für ziemlich fragwürdig. Pi-Hole soll Werbung heraus filtern, leitet aber alle DNS-Anfragen an die Datenkrake Google weiter. Also musste ich hier noch einen weiteren DNS-Server konfigurieren. Dazu nahm ich die Adresse meines Routers (einer FritzBox), der wiederum die Nameserver meines ISP fragt: - DNS2=192.168.0.1
   2. Dnsmasq fragt per Default immer beide Nameserver gleichzeitig und nicht nacheinander, wie es andere Resolver (wie z.B. Bind) tun. Das hat zur Folge, das das erste eintreffende Ergebnis genommen wird. Ist der 2. Nameserver also der von Google, kann dieser natürlich nicht die internen Adressen auflösen. Aber auch in meinem Fall war der zweite Nameserver, der die Nameserver meines ISPs nutze. Die kennen meine internen Adressen aber auch nicht.
   3. Also setzte ich den zweiten Nameserver auf die IP-Adresse der dem Router nachgelagerten OPNSense-Firewall: - DNS1=192.168.1.1 Diese wiederum nutzt auch dnsmasq als DNS-Forwarder! Und hinzu kommt, dass das Standardverhalten von dnsmasq auch ist, Rebind-Attacken zu verhindern. Er löst also auch keine internen Adressen auf! Dazu musste ich ihn erst überreden. Mit der erweiterten Option rebind-domain-ok=<interne Domain> wird der Rebind-Schutz für die interne Domain aufgehoben. Das ist nicht tragisch, da der DNS nur auf dem internen Interface der Firewall läuft und damit von aussen gar nicht angesprochen werden kann.
      Zusätzlich habe ich auch die Option Query DNS servers sequentially gesetzt, da natürlich auch die Firewall noch einen zweiten Resolver konfiguriert hat: meine Fritzbox!

Damit bin ich endlich soweit, dass auch interne Adressen aufgelöst werden, wenn der Pi-Hole als primärer DNS-Server in meinem Netz genutzt wird.