Pi-hole lief, nur fragte ihn niemand: DHCP verteilte nach dem Routerwechsel den falschen DNS

Der Auslöser war ein fremder Migrationsbericht, in dem hartkodierte IP-Adressen die Hauptfehlerquelle waren. Also wollte ich meine eigenen Altlasten loswerden und interne Dienste über Namen statt Adressen ansprechen. Pi-hole läuft ohnehin als lokaler DNS — dort habe ich eine Zone home.arpa angelegt: Host-Records für Router, Server und Pi, plus local=/home.arpa/, damit dnsmasq für diese Zone selbst antwortet und nichts davon nach draußen fragt.

Warum home.arpa und keine ausgedachte Endung wie .lan? RFC 8375 reserviert die Domäne genau für Heimnetze. Sie ist öffentlich nicht delegiert, Unbound und dnsmasq behandeln sie speziell, und anders als .local kollidiert sie nicht mit mDNS.

Direkt gegen den Pi-hole funktionierte alles. dig lieferte die Adressen, unbekannte Namen bekamen sauber NXDOMAIN. Von jedem Client im LAN dagegen: NXDOMAIN für alle. Die Gegenprobe zeigte, was los war:

dig +short @router.home.arpa   doubleclick.net   # echte Adressen
dig +short @pihole.home.arpa   doubleclick.net   # 0.0.0.0 — geblockt

Der Router verteilte per DHCP sich selbst als DNS-Server, und sein eigener Resolver löst sauber auf. Seit dem Routerwechsel ging also der gesamte LAN-Verkehr am Pi-hole vorbei — kein Blocking, keine lokalen Records, und niemand hat es gemerkt, weil DNS ja funktionierte. Für das Monitoring habe ich dem blackbox-exporter im Compose explizit den Pi-hole als dns: mitgegeben; die DHCP-Option selbst habe ich einen Tag später umgestellt (siehe die API-Geschichte dazu).

Drei Folgebefunde kamen mit der Umstellung des Control Centers auf Namen:

• Nextcloud wieder HTTP 400. Die trusted_domains enthielten trotz des Fixes vom Vortag weiter zwei alte Adressen — ich hatte ergänzt statt aufgeräumt, und der neue Name fehlte. Liste komplett durchgegangen, Probe grün, zum ersten Mal seit der Migration.
• VitePress-Docs HTTP 403. Vite lehnt unbekannte Hostnamen ab (Schutz gegen DNS-Rebinding); server.allowedHosts ergänzt.
• Jellyfin gar keine Antwort. Der Container läuft mit network_mode: host — und verhält sich für die Host-Firewall damit wie ein Host-Dienst, während Dienste mit published Ports über den Forward-Pfad unbemerkt weiterlaufen. Regel ergänzt, am 26.08. waren alle zehn HTTP-Checks grün.

Was bleibt: „DNS funktioniert" heißt nicht „DNS läuft wie gedacht". Nach einem Routerwechsel nicht nur die Leases prüfen, sondern auch, welchen DNS-Server DHCP tatsächlich verteilt. Und im Monitoring zweistufig denken: Service-Checks über Namen — eine kaputte Auflösung ist dort ein ehrlicher Befund —, die Erreichbarkeit der Hosts selbst weiter über Adressen.