Telekom Homepage-Center funktioniert mit Pi-hole nicht – Ursache und Lösung

Veröffentlicht am 13. Juli 2026 · zuletzt aktualisiert am 30. September 2026 / in Technik

Kurz gesagt

Das Telekom Homepage-Center war aus meinem lokalen Netzwerk nicht erreichbar. Die DNS-Abfrage für homepage.t-online.de lieferte über Pi-hole zunächst 0.0.0.0, über einen externen Resolver dagegen eine reguläre Adresse. Damit war die Ursache auf die lokale DNS-Filterung eingegrenzt.

Ich habe den benötigten Host als exakte Allowlist-Ausnahme freigegeben, den DNS-Cache geleert und anschließend erneut geprüft. Danach wurde die Domain wieder regulär aufgelöst und der Zugriff funktionierte.

Geeignet für: Betreiber eines eigenen Pi-hole mit einer fälschlich blockierten Website.
Lesezeit: ca. 5 Minuten

Das Problem: Beim Aufruf des Telekom Homepage-Centers erscheint ERR_ADDRESS_INVALID, oder die DNS-Abfrage über Pi-hole liefert 0.0.0.0.

Ausgangssituation

Das Telekom Homepage-Center beziehungsweise die zugrunde liegende Verwaltungsoberfläche funktionierte in meinem Netzwerk nicht mehr. Andere Internetseiten waren erreichbar. Ein allgemeiner Ausfall des Internetzugangs war daher unwahrscheinlich.

Im Browser erschien sinngemäß der Fehler ERR_ADDRESS_INVALID. Statt zunächst Browser, Webserver oder Internetanschluss wahllos zu verändern, prüfte ich deshalb die Namensauflösung.

DNS-Test gegen Pi-hole

Der erste belastbare Test war eine gezielte DNS-Abfrage:

nslookup homepage.t-online.de <PI-HOLE-IP>

Die Antwort enthielt:

0.0.0.0

0.0.0.0 ist hier keine reguläre Zieladresse. Die Antwort zeigte, dass die Domain lokal abgefangen beziehungsweise blockiert wurde.

Vergleich mit einem externen Resolver

Anschließend prüfte ich dieselbe Domain gegen einen externen Resolver:

nslookup homepage.t-online.de 1.1.1.1

Der externe Resolver lieferte eine reguläre Adresse. Damit war der Unterschied belegt:

Ursache eingrenzen

Die Messung bewies eine lokale DNS-Blockierung. Sie bewies jedoch nicht nachträglich, welche einzelne abonnierte Liste den ursprünglichen Treffer ausgelöst hatte. Ohne den damaligen Eintrag im Query-Log wäre eine eindeutige Zuordnung Spekulation.

Deshalb dokumentiere ich nur das Belegte:

• Pi-hole lieferte zunächst 0.0.0.0.
• Ein externer Resolver lieferte eine reguläre Adresse.
• Nach der engen Ausnahme und erneuten Prüfung funktionierte der Zugriff.

Warum passiert das?

Pi-hole filtert Domains auf DNS-Ebene. Wird ein für die aufgerufene Seite benötigter Host von einer Blockliste erfasst, liefert Pi-hole statt einer regulären Zieladresse eine Sperrantwort. Der Browser kann den Dienst deshalb nicht erreichen.

Entscheidung: enge Allowlist

Meine Empfehlung: Pi-hole nicht deaktivieren. Nur den nachweislich benötigten Host als exakte Allowlist-Ausnahme freigeben – keine pauschale Freigabe von *.t-online.de.

Für den konkreten Fehler war der entscheidende Eintrag:

homepage.t-online.de

Die Ausnahme wurde als Exact allow eingerichtet. Weitere beim Seitenaufruf beobachtete Hosts – beispielsweise ebs10.telekom.de, tags.tiqcdn.com und tags-eu.tiqcdn.com – sollten nicht automatisch übernommen werden. Insbesondere die beiden tiqcdn.com-Hosts gehören zu einer Tag-Management-Infrastruktur. Sie werden nur dann freigegeben, wenn ein getrennter Funktionstest ihre Notwendigkeit für die tatsächlich benötigte Verwaltungsfunktion belegt.

Typische Fehler:
✗ Pi-hole vollständig abschalten
✗ eine vollständige Anbieter-Domain per Wildcard erlauben
✓ nur den tatsächlich benötigten Host freigeben und anschließend prüfen

Umsetzung

Der praktische Ablauf:

1. Im Pi-hole Query-Log nach der blockierten Domain suchen.
2. Den benötigten Host als exakte Allowlist-Ausnahme eintragen.
3. Keine Wildcard für eine vollständige Anbieter-Domain verwenden.
4. DNS-Cache des Arbeitsplatzes leeren:

ipconfig /flushdns

5. DNS-Abfrage und Browserzugriff erneut testen.

Router, interner DNS-Dienst und Pi-hole erfüllen in meiner Umgebung getrennte Aufgaben. Pi-hole ist ausschließlich für die DNS-Filterung zuständig. Einzelheiten der internen Netzarchitektur und der Firewall-Regeln gehören in die geschützte technische Dokumentation, nicht in einen öffentlichen Fehlerbericht.

Ergebnis prüfen

Nach der Freigabe lieferten Pi-hole und der externe Resolver wieder reguläre Antworten. Danach war die Weboberfläche erreichbar.

Ein erfolgreicher Browseraufruf allein genügt mir nicht als Nachweis. Zur Kontrolle gehören:

• reguläre DNS-Antwort über Pi-hole,
• erneuter Browserzugriff,
• Prüfung, ob die Ausnahme exakt und nicht als Wildcard angelegt ist,
• Dokumentation von Anlass, Umfang und Ergebnis.

Praxisstand vom 30. September 2026

Die gezielten Freigaben sind in meiner Umgebung weiterhin für die Telekom-Verwaltungsfunktionen erforderlich. Die fünf vorhandenen exakten Allowlist-Einträge blieben bei der Überarbeitung der Filterlisten erhalten. Ihre Notwendigkeit ist eine Erfahrung aus meinem Betrieb, keine pauschale Empfehlung, diese fünf Ausnahmen in andere Installationen zu übernehmen.

Eingesetzte Versionen

Diese Versionen entsprachen am 30. September 2026 den neuesten offiziellen Releases. Der datierte Vergleich ist eine Momentaufnahme; vor einem späteren Update sind die Docker-Releases, Core-Releases, FTL-Releases und Web-Releases erneut zu prüfen.

Aktive Filterlisten

HaGeZi PRO++ baut auf PRO auf. Deshalb verwende ich nur eine der beiden Multi-Stufen. PRO++ filtert aggressiver und kann auch benötigte Domains treffen; für eine neue Installation empfiehlt HaGeZi die ausgewogenere PRO-Stufe. TIF ist als Ergänzung vorgesehen. Die Auswahl hängt damit vom gewünschten Filterumfang und der Bereitschaft ab, Fehlblockierungen gezielt zu beheben. Siehe HaGeZi-Dokumentation. StevenBlack ist der Vorschlag im offiziellen Pi-hole-Installationsskript; die hier verwendete Dreierkombination ist meine eigene Betriebsauswahl.

Die letzte manuelle Gravity-Aktualisierung am 30. September 2026 wurde erfolgreich abgeschlossen: PRO++ wurde geladen, TIF Mini und StevenBlack waren unverändert verfügbar. Pi-hole meldete 477.819 eindeutige Sperreinträge. Diese Zahl beschreibt den damaligen Datenbankstand, nicht die Zahl unterschiedlicher Bedrohungen oder ein Maß für die Schutzqualität. Adblock-Regeln können außerdem ganze Domainbereiche erfassen und überschneiden sich in ihrer Wirkung mit exakten Hosts-Einträgen.

Aktualisierung und Geschwindigkeit einordnen

Pi-hole aktualisiert die Filterlisten standardmäßig einmal pro Woche am frühen Sonntagmorgen. Der zuletzt vor dieser Bearbeitung angezeigte automatische Lauf vom 27. September 2026 passte dazu. Der konkrete Zeitplan im laufenden Container wurde nicht geprüft. Eine Gravity-Aktualisierung aktualisiert die Filterdatenbank, nicht die Pi-hole-Software. Quelle: offizieller Pi-hole-Zeitplan.

Wiederholte DNS-Testabfragen wurden in dieser Prüfung schnell beantwortet. Eine Beschleunigung gegenüber dem früheren Listenbestand ist damit jedoch nicht belegt: Dafür fehlt eine vergleichbare Messung vor der Umstellung. Weniger Listeneinträge allein sind kein Nachweis schnellerer Internetseiten.

Die vorhandene DNS-Ausfallsicherheit bleibt Teil meiner Netzkonfiguration. Die Filterung soll den Betrieb ergänzen; der Ausfall des Pi-hole darf die Namensauflösung nicht vollständig unterbrechen. Die interne Umsetzung bleibt in der geschützten technischen Dokumentation.

Was künftig dokumentiert werden sollte

Bei einer neuen Ausnahme halte ich fest:

• welches konkrete Fehlerbild auftrat,
• welche Domain blockiert wurde,
• welcher Query-Log-Eintrag die Ursache zeigte,
• welche exakte Ausnahme eingerichtet wurde,
• ob zusätzliche Hosts wirklich erforderlich waren,
• wann die Ausnahme erneut geprüft werden soll.

Merksatz: Eine Allowlist ist eine begründete Ausnahme von einer Sicherheitsregel – keine beiläufige Komforteinstellung.

Das nehme ich mit

Pi-hole war nicht defekt. Eine Blockliste erfasste einen benötigten Host. Der entscheidende Hinweis war die unterschiedliche DNS-Antwort: lokal 0.0.0.0, extern eine reguläre Adresse.

Eine gezielte Allowlist-Ausnahme löste das Problem, ohne den Schutz vollständig aufzugeben. Der übertragbare Wert liegt im Vorgehen: messen, vergleichen, gezielt entscheiden und das Ergebnis erneut prüfen.

Weiterführend

• Digitale Souveränität und warum Programme nur Werkzeuge sind