Pi-hole Wildcard DNS: ein Eintrag für alle Subdomains

Zwei Formulare pro Dienst. So endete die Anleitung zum Nginx Proxy Manager: ein Eintrag in Pi-hole, der den Namen auf den Proxy zeigt, und ein Proxy Host in NPM, der den Namen an den richtigen Port reicht. Bei zehn Diensten sind das zwanzig Formulare, und zehn davon haben Wort für Wort denselben Inhalt: Dieser Name zeigt auf 192.168.178.20. Zehnmal dieselbe IP-Adresse eintippen ist genau die Art Arbeit, für die man Computer erfunden hat.

Heute streichen wir die Pi-hole-Hälfte. Ein einziger Eintrag sagt ab jetzt: Alles, was auf home.arpa endet, geht an den Proxy. Ein neuer Dienst ist danach nur noch ein Proxy Host, und Pi-hole muss davon nichts mehr wissen. Und weil die Suche nach „fritzbox wildcard dns“ ebenfalls hier landet: Die Antwort dazu steht weiter unten, sie ist kurz.

Warum Local DNS Records keinen Platzhalter kennen

Die Seite Local DNS Records in Pi-hole funktioniert wie ein Telefonbuch: eine Zeile, ein Name, eine Nummer. Ein Eintrag „alle, die mit home.arpa enden“ passt in dieses Format nicht, und das ist kein Versehen. Der Wunsch danach liegt seit Mai 2020 im Forum, und Entwickler DL6ER hat ihn am 07-11-2023 endgültig beantwortet: Die Einträge sind absichtlich wie eine hosts-Datei gebaut, und Platzhalter kennt dieses Format schlicht nicht. Das heißt für dich: Darauf warten lohnt nicht, der Weg ist ein anderer, und er ist seit Jahren derselbe.

Er führt zu dnsmasq. Das ist das DNS-Programm, das in Pi-hole steckt; Pi-hole hat es umgebaut und nennt seine Ausgabe FTL. dnsmasq kennt eine Option, die genau das tut, was das Telefonbuch nicht kann. Sie heißt address, und die Zeile für unser Ziel sieht so aus:

address=/home.arpa/192.168.178.20

Übersetzt aus dem dnsmasq-Handbuch: Für jeden Host in dieser Domain gib diese IP-Adresse zurück, und frag dafür nie einen anderen DNS-Server. „Jeder Host“ heißt home.arpa selbst und alles davor: kuma.home.arpa, jellyfin.home.arpa, auch test.neu.home.arpa. Das Handbuch ist genau bei der Grenze: Verglichen wird in ganzen Namensteilen, /google.com/ trifft www.google.com, aber nicht supergoogle.com. Ein Name, den es nie gab, bekommt dieselbe Antwort wie einer, den du gestern angelegt hast. Genau das wollen wir, denn den Rest entscheidet der Proxy anhand des Namens:

Was seit dem 19-09-2026 anders ist

Bis vorgestern stand diese Zeile in Pi-hole 6 in der Weboberfläche: unter All settings im Reiter Miscellaneous, Feld misc.dnsmasq_lines. So haben es die Pi-hole-Leute im Forum im Februar 2025 selbst empfohlen, und so steht es in Anleitungen im Netz. Mit FTL 6.7.1 vom 19-09-2026 ist das Feld aus Oberfläche und API verschwunden. Der Grund steht in einem Sicherheitshinweis des Projekts, Einstufung hoch: dnsmasq kennt Optionen, die Programme starten, etwa dhcp-script. Wer in der Oberfläche angemeldet war, konnte so eine Zeile eintragen und damit beliebige Befehle auf dem Pi-hole-Rechner ausführen. Ohne Passwort für die Oberfläche: jeder im Netz.

Ich finde die Entscheidung richtig. Ein Textfeld, das beliebige Zeilen ungeprüft an ein Programm mit weitreichenden Rechten durchreicht, war eine Tür zum Betriebssystem, und die gehört nicht in eine Oberfläche, die im ganzen Haus erreichbar ist. Die Zeile selbst ist geblieben, nur der Weg dorthin verlangt jetzt, dass du auf dem Rechner bist: über die Shell, in der Konfigurationsdatei oder, bei Docker, über die Compose-Datei. Für dich heißt das zweierlei. Jede Anleitung, die dich zu „All settings“ schickt, war bis vorgestern korrekt und führt jetzt ins Leere. Und wer noch eine ältere FTL-Version hat, macht zuerst das Update, nicht wegen der Wildcard, sondern wegen der Lücke.

Was du brauchst

• Pi-hole 6, entweder direkt installiert wie in der LXC-Anleitung oder als Container wie im Docker-Beitrag. Beide Wege stehen unten.
• Deine Geräte fragen Pi-hole. Bei der FritzBox ist das der Eintrag als lokaler DNS-Server; ohne ihn bekommt niemand deine Namen zu sehen.
• Einen Reverse Proxy mit mindestens einem Host, der schon über seinen Namen antwortet. Ich nehme den Stand aus der NPM-Anleitung: kuma.home.arpa führt zu Uptime Kuma.
• Zugang zur Kommandozeile des Rechners, auf dem Pi-hole läuft: per SSH, oder bei einem LXC über die Konsole in Proxmox.

Alle Befehle rechnen mit denselben Beispielwerten, es sind die aus der NPM-Anleitung. Wo sie unten auftauchen, setzt du deine ein:

Ob die Voraussetzungen stehen, zeigt ein Befehl von deinem PC aus. Unter Windows in der Eingabeaufforderung nslookup kuma.home.arpa, unter Linux und macOS im Terminal:

dig kuma.home.arpa

Zwei Stellen der Ausgabe zählen: In der Zeile, die mit ;; SERVER: beginnt, steht die 192.168.178.53, also fragt dein PC das richtige Gerät. Und unter ANSWER SECTION steht in der Zeile mit dem A die 192.168.178.20, die Adresse des Proxy. nslookup zeigt dieselben beiden Angaben als Server und Address. Steht dort ein anderer Server, meist der Router, dann fehlt der Schritt aus der FritzBox-Anleitung; die Wildcard würde dann zwar in Pi-hole stehen, aber niemand fragt danach.

Schritt 1: Version prüfen

Die Zeile funktioniert in jedem Pi-hole 6. Die Versionsprüfung ist trotzdem der erste Schritt, wegen der Lücke von oben: Alles unter FTL 6.7.1 hat sie noch.

pihole -v

cd ~/pihole
docker compose exec pihole pihole -v

Core version is v6.4.3 (Latest: v6.4.3)
Web version is v6.6 (Latest: v6.6)
FTL version is v6.7.1 (Latest: v6.7.1)

Steht in der FTL-Zeile etwas Älteres, kommt erst das Update. Vorher der Satz, den ich in jedem Beitrag sage und der bei einem DNS-Server, den das ganze Haus benutzt, zu Recht dort steht: Unter Settings, Teleporter, Export holst du dir eine Zip-Datei mit deinen Einstellungen, bevor du etwas anfasst.

sudo pihole -up

cd ~/pihole
docker compose pull && docker compose up -d

Danach noch einmal pihole -v; jetzt steht dort die 6.7.1. Beim Container hängt die FTL-Version am Image, das aktuelle Docker-Tag 2026.09.0 vom 19-09-2026 bringt sie mit.

Schritt 2: Die eine Zeile setzen

Jetzt kommt die Zeile in Pi-hole hinein, und zwar in die Einstellung misc.dnsmasq_lines. Das ist laut Doku eine Liste von dnsmasq-Zeilen, die Pi-hole ans Ende seiner eigenen Konfiguration hängt. Es gibt zwei Wege, je nachdem, wie dein Pi-hole läuft. Beide führen zum selben Ergebnis, und du gehst einen davon.

Weg A: Pi-hole ist direkt installiert (LXC, Raspberry Pi, ein eigener Rechner). Die Einstellung setzt du mit dem Werkzeug pihole-FTL --config, das Pi-hole mitbringt:

sudo pihole-FTL --config misc.dnsmasq_lines '["address=/home.arpa/192.168.178.20"]'

[ "address=/home.arpa/192.168.178.20" ]

Der Befehl wiederholt als Antwort die Liste, die er gerade gespeichert hat. Die eckigen Klammern sind die Liste, die doppelten Anführungszeichen gehören zur Zeile darin, und die einfachen außen herum sorgen dafür, dass die Shell das Ganze unangetastet weiterreicht; das ist die Schreibweise aus der Pi-hole-Doku. Brauchst du später eine zweite Zeile, kommt sie mit Komma in dieselbe Liste, denn der Befehl ersetzt die Liste immer als Ganzes.

Neu starten musst du nichts. Wenn ich den FTL-Quellcode richtig lese, beobachtet Pi-hole seine Konfigurationsdatei /etc/pihole/pihole.toml, in die der Befehl schreibt, und bei genau dieser Einstellung startet es sich selbst neu; im Log steht dann „Restarting FTL due to change of misc.dnsmasq_lines“. Das dauert ein paar Sekunden, in denen im Haus kein DNS beantwortet wird. Wer gerade einen Film streamt, merkt davon nichts, wer gerade eine Seite lädt, drückt einmal auf Neu laden.

Weg B: Pi-hole läuft als Container. Dann ist die Compose-Datei die einzige Wahrheit, und die Einstellung kommt als Umgebungsvariable hinein. Die Regel dafür aus der Docker-Doku von Pi-hole: Aus misc.dnsmasq_lines wird FTLCONF_misc_dnsmasq_lines.

cd ~/pihole
nano docker-compose.yml

      # home.arpa und alle Namen darunter zeigen auf den Reverse Proxy
      FTLCONF_misc_dnsmasq_lines: "address=/home.arpa/192.168.178.20"

docker compose config --quiet && echo OK
docker compose up -d
docker compose ps

Bei STATUS muss wieder Up stehen; Pi-hole braucht nach dem Start etwa eine halbe Minute, bis es auf Port 53 antwortet. Mehrere Zeilen trennst du in dieser Variable laut Doku mit einem Semikolon. Und weil die Einstellung aus der Umgebung kommt, ist sie ab jetzt schreibgeschützt, so beschreibt es die Doku: Änderungen gehen nur über die Datei, nicht über pihole-FTL --config im Container. Zum Nachsehen taugt der Befehl trotzdem:

docker compose exec pihole pihole-FTL --config misc.dnsmasq_lines

Noch ein Wort zur Endung. home.arpa ist für Heimnetze reserviert, das habe ich in der NPM-Anleitung erklärt. Wer lieber etwas anderes will, tauscht es in der Zeile aus, mit zwei Ausnahmen: .local gehört einem anderen Verfahren und kommt bei Pi-hole gar nicht erst an. Und lan ist laut Doku der Standardwert für Pi-holes eigene Domain, unter der es Geräte aus seinem DHCP kennt; eine Wildcard darauf würde diese Gerätenamen gleich mit zum Proxy schicken.

Schritt 3: Prüfen, mit einem Namen, den es nie gab

Der Beweis, dass die Regel greift und nicht ein alter Einzeleintrag, ist eine Frage nach einem Namen, den du nie angelegt hast. Von deinem PC aus, ausdrücklich an Pi-hole gerichtet:

nslookup irgendwas.home.arpa 192.168.178.53

dig +short irgendwas.home.arpa @192.168.178.53

192.168.178.20

Eine Zeile, die Adresse des Proxy, für einen Namen, den es vor einer Minute noch nicht gab. Das ist der Moment, in dem sich der ganze Beitrag bezahlt macht, und der darf kurz gefeiert werden. Dann dieselbe Frage ohne das @ beziehungsweise ohne die IP am Ende: So fragt dein PC über seinen normalen Weg, und die Antwort muss dieselbe sein. Ist sie es nicht, steht die Ursache unten bei „Wo es klemmt“.

Jetzt der eigentliche Zweck. Jellyfin soll jellyfin.home.arpa heißen, und dafür fasst du Pi-hole nicht mehr an:

Im Browser http://jellyfin.home.arpa eintippen: Jellyfin erscheint. Pi-hole hat den Namen nie gesehen und trotzdem richtig beantwortet, weil er auf home.arpa endet. Ab heute ist jeder weitere Dienst ein einziges Formular, und das Telefonbuch in Pi-hole bleibt so kurz, wie es ist.

Schritt 4: Die Einzeleinträge aufräumen

Der Eintrag kuma.home.arpa aus der NPM-Anleitung steht noch in den Local DNS Records und zeigt auf dieselbe Adresse wie die Regel. Er stört nicht, aber er ist der erste einer Sorte, die du ab jetzt nicht mehr brauchst. Bevor du löschst, die Vorrangregel aus dem dnsmasq-Handbuch, weil sie entscheidet, was bleiben muss: Einträge aus der hosts-Datei gewinnen bei einzelnen Namen gegen die address-Zeile, und Pi-hole schreibt seine Local DNS Records in genau so eine Datei. Ein Eintrag, der auf eine andere Adresse zeigt als die Regel, etwa pihole.home.arpa auf die 192.168.178.53, bleibt also nötig und gewinnt. Ein Eintrag, der auf den Proxy zeigt, ist doppelt und kann weg.

Zur Kontrolle einmal dig +short kuma.home.arpa @192.168.178.53: Die Antwort ist weiterhin die 192.168.178.20, nur kommt sie jetzt von der Regel. Und http://kuma.home.arpa im Browser öffnet Uptime Kuma wie vorher.

Und die FritzBox?

Die Frage taucht in der Suche auf, also die Antwort: Die Box ist für diese Aufgabe der falsche Ort. Sie vergibt Namen unter fritz.box an die Geräte, die sie kennt, und dabei bleibt es; ein Formular für eigene Namen oder gar Platzhalter hat ihre Oberfläche nicht. Die Wildcard wohnt deshalb in Pi-hole, und die FritzBox hat nur eine Aufgabe: allen Geräten zu sagen, dass sie Pi-hole fragen sollen. Das ist der Eintrag als lokaler DNS-Server aus der FritzBox-Anleitung.

Ein Fall braucht einen Nachsatz. Manche tragen Pi-hole stattdessen unter Internet, Zugangsdaten, DNS-Server ein, so dass die Geräte weiter die Box fragen und die Box dann Pi-hole. Die Pi-hole-Doku warnt vor diesem Aufbau wegen der Schleife, die entsteht, wenn zugleich die Box als Upstream in Pi-hole steht. Und für die Wildcard kommt der DNS-Rebind-Schutz der Box dazu. Bucking_Horn aus dem Pi-hole-Team hat ihn 2020 im Forum erklärt: Die Box unterdrückt Antworten ihres Upstream-DNS, wenn darin eine lokale IP-Adresse steht, und genau das ist jede Antwort der Wildcard. Eine Ausnahme dafür trägst du unter Heimnetz, Netzwerk, Netzwerkeinstellungen, DNS-Rebind-Schutz ein, ein Name pro Zeile, hier home.arpa. Ich würde den Umweg nicht gehen. Mit Pi-hole als lokalem DNS-Server sieht die Box die Antworten gar nicht, und es gibt nichts auszunehmen; das sagt derselbe Forums-Beitrag.

Was am Ende eingestellt ist

Die Regel läuft, das Telefonbuch ist kurz. Vier Dinge gehören noch dazu.

1. Ein Ort für die Regel, und der gehört ins Backup. Bei Weg A steht die Zeile jetzt in /etc/pihole/pihole.toml, bei Weg B in deiner Compose-Datei. Der Ordner /etc/pihole beziehungsweise ~/pihole samt Compose-Datei gehört in dein normales Backup; der Teleporter-Export aus Schritt 1 ist die Ergänzung, kein Ersatz.

2. Der alte Ordner /etc/dnsmasq.d ist in Pi-hole 6 aus. Wer in Pi-hole 5 seine Wildcard als Datei dort abgelegt hatte, hat nach dem Umstieg gemerkt, dass sie nichts mehr tut; auf GitHub liegt dazu ein Issue vom 20-02-2025. Die Pi-hole-Leute haben es im Forum zwei Tage später erklärt: Der Ordner wird laut Doku nur noch gelesen, wenn die Einstellung misc.etc_dnsmasq_d auf true steht, und dann laut Quellcode auch nur Dateien mit der Endung .conf. Du könntest den Schalter umlegen. Ich würde stattdessen die Zeilen aus solchen Dateien in misc.dnsmasq_lines umziehen und den Ordner leer lassen: ein Ort, an dem alles steht, statt zwei, die sich widersprechen können.

3. Die Regel bleibt im Haus. Die address-Zeile antwortet selbst und fragt nie einen Server draußen, so steht es im Handbuch, und home.arpa hat ohnehin nichts im Internet zu suchen. Anders wird es, wenn du statt home.arpa eine echte Domain nimmst, weil du später Zertifikate dafür willst. Bucking_Horn aus dem Pi-hole-Team hat schon 2020 auf den Haken hingewiesen: Die Regel unterscheidet nicht zwischen der Domain und ihren Subdomains. address=/meinedomain.de/ schickt auch www.meinedomain.de zum Proxy, und deine öffentliche Website ist von zu Hause aus nicht mehr erreichbar. Nimm dann einen Unterbereich, etwa address=/home.meinedomain.de/192.168.178.20.

4. HTTPS fehlt weiterhin. Die Namen sind bequemer geworden, verschlüsselt ist nichts davon, der Browser sagt vor jedem Namen weiter „Nicht sicher“. Das ändert die Wildcard nicht, und der Weg zum Schloss steht am Ende der NPM-Anleitung: eigene Domain, Zertifikat über den DNS-Anbieter, ein Beitrag für sich.

Wo es klemmt

Das Feld misc.dnsmasq_lines ist unter All settings nicht mehr da, oder die Oberfläche nimmt die Änderung nicht an. Seit FTL 6.7.1, siehe oben. Die Anleitung, aus der du das hast, war bis zum 19-09-2026 richtig. Der Befehl aus Schritt 2 ist der Weg.

Die Antwort mit @192.168.178.53 stimmt, ohne stimmt sie nicht. Pi-hole macht alles richtig, aber dein Gerät fragt jemand anderen. Der Klassiker ist der Router, der sich per IPv6 als zweiter DNS-Server anbietet; in der FritzBox-Anleitung ist das Schritt 2. Unter Windows kann es auch die Erinnerung des Rechners sein: Hat er den Namen kurz vorher als unbekannt gelernt, behält er das eine Weile. ipconfig /flushdns in der Eingabeaufforderung leert laut Microsoft-Doku genau diesen Zwischenspeicher, samt der negativen Antworten.

Der PC findet den Namen, das Handy nicht. Dieselbe Ursache, anderes Gerät: Das Handy fragt nicht Pi-hole. Erst IPv6 in der FritzBox-Anleitung prüfen, dann auf dem Handy, ob ein „privates DNS“ eingestellt ist, das an Pi-hole vorbeigeht.

Meine Datei in /etc/dnsmasq.d wird ignoriert. Punkt 2 von oben: In Pi-hole 6 ist der Ordner abgeschaltet, und die Lösung ist der Umzug in misc.dnsmasq_lines.

Im Container meldet pihole-FTL --config, der Wert lasse sich nicht ändern. Richtig so: Was per Umgebungsvariable gesetzt ist, ist laut Doku schreibgeschützt. Die Compose-Datei ändern, docker compose up -d, fertig.

Eine Zeile, und aus zwei Formularen pro Dienst wird eines. Was mir daran gefällt, ist weniger die gesparte Minute als das Prinzip dahinter: Die Entscheidung, welcher Name wohin führt, liegt jetzt an einer Stelle, beim Proxy, und Pi-hole beantwortet nur noch die Frage, für die es zuständig ist.

Wie viele Einzeleinträge sind bei dir gerade überflüssig geworden, und welche Endung hast du genommen? Schreib es in die Kommentare, mich interessiert auch, ob jemand den alten Weg über /etc/dnsmasq.d noch am Laufen hatte, ohne es zu merken.

Wenn dir der Proxy für die andere Hälfte noch fehlt: In der NPM-Anleitung ist er in einer halben Stunde da, und mit der Wildcard von heute überspringst du dort gleich Schritt 3.

Quellen

• Pi-hole-Doku: FTL-Konfiguration (misc.dnsmasq_lines, misc.etc_dnsmasq_d, dns.hosts, dns.domain, pihole-FTL --config, Umgebungsvariablen sind schreibgeschützt)
• Pi-hole-Doku: Docker Configuration (FTLCONF_-Schema, Beispiel FTLCONF_misc_dnsmasq_lines mit address=, Trennung per Semikolon)
• Pi-hole FTL: Release v6.7.1 vom 19-09-2026 (misc.dnsmasq_lines nicht mehr über API und Weboberfläche)
• GitHub Security Advisory GHSA-ww5x-xx4x-qvjr: Remote code execution via exec-capable options in misc.dnsmasq_lines (hoch, CVSS 7.2, betroffen FTL ab 6.0, behoben in 6.7.1)
• pi-hole/docker-pi-hole: Releases (2026.09.0 vom 19-09-2026 mit FTL v6.7.1, Core v6.4.3, Web v6.6)
• dnsmasq-Handbuch: --address (Antwort für alle Hosts einer Domain, nie weitergeleitet, /etc/hosts hat bei einzelnen Namen Vorrang, Vergleich in ganzen Namensteilen)
• Pi-hole-Forum: Support wildcards in Local DNS Records (Feature-Request vom 12-05-2020; DL6ER am 07-11-2023: absichtlich HOSTS-artig; Bucking_Horn am 17-06-2020: kein Unterschied zwischen Domain und Subdomains)
• Pi-hole-Forum: How to add address custom dnsmasq configuration lines to Pi-hole v6 (rdwebdesign am 22-02-2025 zu /etc/dnsmasq.d; Bucking_Horn am 23-02-2025 mit dem pihole-FTL --config-Beispiel und dem damaligen Weg über All settings)
• pi-hole/pi-hole: Issue #5925, Custom dnsmasq for local wildcard DNS no longer working in v6 (20-02-2025)
• pi-hole/FTL: src/config/dnsmasq_config.c (conf-dir=/etc/dnsmasq.d,*.conf nur bei etc_dnsmasq_d; hostsdir für Local DNS Records; dnsmasq_lines werden angehängt)
• pi-hole/FTL: src/config/toml_reader.c („Restarting FTL due to change of …“ bei Einstellungen mit Neustart-Flag)
• pi-hole/FTL: src/gc.c (Überwachung von pihole.toml per inotify, reread_config)
• pi-hole/pi-hole: version.sh (Ausgabeformat von pihole -v)
• Pi-hole-Doku: The pihole command (pihole -v, pihole -up)
• pi-hole/web: footer.js (Versionen in der Fußzeile: Docker Tag, Core, FTL, Web interface; „Update available!“)
• pi-hole/web: settings-dnsrecords.lp (Local DNS records, Felder Domain und IP, Löschen leert den Cache ohne Neustart)
• Pi-hole-Doku: Fritz!Box (Lokaler DNS-Server unter Heimnetz › Netzwerk › Netzwerkeinstellungen; Warnung vor der Schleife über Internet › Zugangsdaten › DNS-Server)
• Pi-hole-Forum: DNS-Rebind auf FritzBox, Risiken und Konfiguration (Bucking_Horn am 01-04-2020: Box unterdrückt Upstream-Antworten mit lokaler IP; Ausnahme nur bei Pi-hole als Upstream sinnvoll, Name oder Adresse pro Zeile)
• Microsoft Learn: ipconfig (/flushdns leert den DNS-Cache samt negativer Einträge)