Homelab, zweiter Schritt — wem der DNS-Server vertraut#

Der erste Teil endete mit einem laufenden Pi-hole und dem Satz, dass ein laufender Dienst und ein benutzter Dienst zwei verschiedene Dinge sind. Drei Punkte standen offen. Zwei davon sind jetzt erledigt, und der dritte ist es bewusst nicht.

Der eine Haken im Router#

Der Filter lief seit Tagen und filterte nichts, weil ihn niemand fragte. Die UDM verteilte per DHCP weiterhin ihre eigene Adresse als Nameserver, und jedes Geraet im Haushalt hielt sich daran — ein Telefonbuch, das im Regal steht, waehrend alle beim alten nachschlagen.

Was das aendert, ist ein einziges Feld: DHCP Name Server, von Auto auf Manual, darin 10.10.10.3. Der Aufwand der Tage davor entschied sich an einem Klick. Wie das Feld genau wirkt, warum dort kein zweiter oeffentlicher Resolver danebengehoert und wann die Geraete es tatsaechlich uebernehmen, steht unter Pi-hole per DHCP verteilen.

Der Beweis kam nicht aus einer Konfigurationsdatei, sondern aus dem laufenden Protokoll: Wo vorher im Wesentlichen der Server selbst auftauchte, liefen ploetzlich die Adressen des halben Haushalts durch. Ein Fernseher, der im Leerlauf alle paar Sekunden irgendwo anfragt, ist eine eigene kleine Erkenntnis.

Der Bibliothekar, der woanders nachschlaegt#

Damit war der Filter in Benutzung — von allen ausser einem. Der Thin Client selbst fragte weiter den Router und einen oeffentlichen Resolver, weil in seiner /etc/resolv.conf noch stand, was der Installer vier Tage zuvor hineingeschrieben hatte. Die einzige Maschine im Haus, die den Filter betreibt, war die einzige, die ihn nicht benutzte.

Praktisch heisst das: Paketquellen, Blocklisten-Aktualisierungen, alles, was der Server von sich aus tut, lief ungefiltert und in keinem Protokoll. Und jeder Test, den man aus Bequem- lichkeit direkt auf der Kiste macht, testet etwas, das gar nicht Pi-hole beantwortet hat.

Die Datei war auch deshalb interessant, weil sie luegt. In ihrem Kopf steht # Generated by dhcpcd — nur gibt es auf dieser Maschine keinen dhcpcd. Der Dienst existiert nicht, resolvconf und openresolv sind nicht installiert, und die Datei traegt unveraendert das Datum der Installation. Sie ist von Hand zu pflegen, und Handaenderungen ueberleben. Meine eigene Notiz warnte an dieser Stelle vor einem Problem, das es hier gar nicht gibt — was einen schoenen Nebeneffekt des Aufschreibens zeigt: Man findet die eigenen ungeprueften Annahmen erst wieder, wenn man sie nachmisst.

Jetzt steht dort eine Zeile, nameserver 127.0.0.1, und zwar bewusst ohne zweiten Eintrag: Faellt Pi-hole aus, loest der Server nichts mehr auf. Das ist unbequem und richtig — ein Ausweicheintrag waere ausgerechnet auf der Filter-Maschine das Loch im Filter. Die Begruendung samt Loopback-Detail steht unter Der DNS-Server fragt sich selbst.

Der Adressat war die ganze Zeit Google#

Bleibt der Punkt, der am unangenehmsten war. Pi-hole kennt die Adressen der Welt nicht; was nicht auf einer Blockliste steht, reicht es weiter — und der Installer schlaegt dafuer Google vor. Wer bestaetigt, hat ein System aufgebaut, das Werbenetzwerke aussperrt und anschliessend jede einzelne Anfrage bei Google abliefert. Sauber gebuendelt hinter einer Adresse.

Der Filter aendert also, wie viele Anfragen das Haus verlassen, nicht ob jemand sie sieht. Das ist eine unangenehme Erkenntnis, wenn man den Aufbau mit Datenschutz begruendet hat.

Es steht jetzt Quad9 dort. Eine Schweizer Stiftung ohne Werbegeschaeft, die keine Client-Adressen speichert und zusaetzlich bekannte Schadsoftware-Domains blockt — was Pi-hole ergaenzt, statt es zu doppeln: hier Werbung und Tracking, dort Malware und Phishing. Ehrlich dazu gehoert, dass auch das nur ein Anbieter ist, dem man vertraut, und dass ein zweiter Filter, den man nicht selbst pflegt, auch mal falsch liegen kann. Die Abwaegung zwischen den Anbietern steht unter Upstream-DNS waehlen.

Und einmal bewusst nichts getan#

Der dritte offene Punkt war DNSSEC — die kryptografische Pruefung, ob eine Antwort unterwegs gefaelscht wurde. Er klang nach dem selbstverstaendlichsten der drei, und beim Nachdenken wurde daraus ein Nein.

Quad9 validiert bereits selbst. Die eigene Pruefung wuerde genau einen Punkt gewinnen: nicht mehr darauf angewiesen zu sein, dass der Upstream ehrlich geprueft hat. Dagegen steht ein reales Ausfallrisiko, denn abgelaufene Signaturen kommen vor, auch bei grossen Betreibern — und dann antwortet eine Domain mit SERVFAIL statt gar nicht. Im Haushalt sieht das aus wie ein Ausfall von Pi-hole, und genau dort wird gesucht.

Der Punkt kommt zurueck, sobald der Upstream ein eigener rekursiver Resolver ist. Dann wird die Pruefung zum eigentlichen Sinn der Uebung, weil die Kette bis zur Root selbst nachgerechnet wird, statt einem Anbieter zu glauben. Bis dahin waere es doppelte Buchfuehrung mit einem zusaetzlichen Ausfallgrund. Was DNSSEC leistet und was nicht, steht trotzdem geschrieben — eine Entscheidung gegen etwas ist nur dann eine, wenn man sie begruenden kann.

Als naechstes: doch das Netz#

Der Aufbau steht damit sauber: Die Geraete fragen den Filter, der Filter fragt einen Anbieter, dem zu vertrauen eine bewusste Entscheidung war, und die Maschine dazwischen filtert auch fuer sich selbst.

Bevor ein zweiter Rechner dazukommt, ist das Netz an der Reihe — fuenf Segmente statt einem flachen /16. Der Plan steht seit einigen Tagen fertig da, samt der Reihenfolge fuer den Umbau-Abend und dem Fallstrick, an dem er sonst kippt: Pi-hole beantwortet mit listeningMode = LOCAL nur Anfragen aus dem eigenen Subnetz, und nach dem Schnitt sind vier Fuenftel des Haushalts genau das nicht mehr. Der Plan steht unter Netz-Layout mit VLANs.

Notizen dazu, wenn es laeuft.