ich betreibe eine Webseite auf meiner eigenen NAS.
Diese ist über eine gekaufte Domain im Internet zugänglich.
Der Einfachheithalber nennen wir sie: meinedomain.de
Nun ist es so, dass mit jedem Reconnect von meinem Router (spätestens also mit der Zwangstrennung) eine neue IP hinter der Domain meinedomain.de steckt.
Die Technik im Hintergrund funktioniert. Das heißt, das der DNS Eintrag mittels eines kleinen Tools alle 5 Minuten aktualisiert wird (funktioniert).
Nur habe ich manchmal das Problem, das Pi-Hole scheinbar nicht "oft genug" die Domain nach ihrer IP auflöst und noch alte IP-Leichen an meine Clients gibt, die dann natürlich nicht connecten können.
Gehe ich zum Beispiel über das mobile Internet meines iPhones dann auf die Webseite meinedomain.de funktioniert es. Daher habe ich Pi-Hole schwer in Verdacht.
Meine Frage:
Kann man Pi-Hole dazu zwingen diese bestimmte Domain beispielsweise alle 10 oder 15 Minuten neu aufzulösen? Wenn ja wie?
Ich scheine ein neuartiges Problem zu haben.
Den Sachverhalt wie oben geschrieben habe ich relativ oft. Dann geht tatsächlich die Seite ohne Pi-Hole.
Nun aber scheint generell ein anderes Problem zu sein.
Der DNS Eintrag ist derzeit falsch (die IP stimmt nicht).
In meinem Customerportal vom Domainanbieter steht das Gültigkeitsflag auch auf unknown statt auf yes.
Immer wieder was Neues
Jedoch bleibt meine Frage nach regelmäßigem Neuauflösen der Domain weiterhin bestehen... zusätzlich zu meinem neuen Problem.
Pi-hole würde den DNS-Datensatz für Deine Domain für 300 Sekunden (also 5 Minuten) cachen und in dieser Zeit auch nicht erneut über einen Upstream-DNS-Server anfragen.
Sollte sich der DNS-Datensatz während dieser Zeit ändern, würde Pi-hole bis zum Ablauf der TTL die vorherige IP-Adresse aus dem Cache ausliefern.
Für nach Ablauf der TTL eintreffende Anfragen würde die Abfrage wieder an einen Upstream-Server gestellt. Je nachdem, wann dieser Upstream-DNS-Server seinerseits Kenntnis von der DNS-Aktualisierung erhält, meldet dieser jedoch u.U. ebenfalls noch die bisher bekannte IP.
DNS-Änderungen brauchen eine Weile, bevor sie in den Caches aller öffentlichen DNS-Resolver aktualisiert sind. Das ist also kein Pi-hole Problem.
Sofern der eigene DNS-Server Deines DynDNS-Providers erreichbar und bekannt ist, könntest Du die Auflösung nur für diese Domäne gezielt an diesen weiterleiten (EDIT: in der Annahme, dass dieser stets die korrekte oder zumindest aktuellste Auflösung kennt).
Das geht über das Anlegen einer server-Option in einer benutzerspezifischen dnsmasq-Konfiguration, z.B. in /etc/dnsmasq.d/99-meine-dyndns.conf:
# send DNS requests for my DynDNS domain to specific server
server=/meinedomain.de/1.2.3.4
1.2.3.4 ist durch die korrekte IP-Adresse des DNS-Servers zu ersetzen.
Der nachfolgende Befehl prüft dann, ob die Konfiguration syntaktisch korrekt ist:
pihole-FTL dnsmasq-test
Wenn das OK meldet, kann Pi-hole neu gestartet werden:
Vielen Dank für deine Antwort.
Wieder etwas schlauer geworden.
Ich werde das nochmal im Auge behalten und ggf. nach dieser Anleitung verfahren.
Für mich heißt das aber auch, dass es keine Möglichkeit gibt die TTL quasi im Pi-Hole zu überschreiben um einer erneute Auflösung zu erzwingen.
Was meinen akuten Fall angeht:
Das scheint sich wieder erledigt zu haben. Es schien am DNS Server meines Providers.
Nach reichlich Wartezeit und dem erneuten Speichern der DNS Einstellungen (ohne Änderung) war es dann irgendwann nach Stunden wieder alles "gültig" und nun funktioniert alles wieder.
Vielen Dank also abschließend nochmal für deine Unterstützung!
Diese Möglichkeit gibt es schon.
Es würde aber keinen Sinn machen, eine erneute Abfrage an die Upstream-DNS-Server zu stellen, wenn die TTL noch nicht abgelaufen ist.
Die befragten DNS-Server verhalten sich gemäß DNS-Protokoll im Zweifel genauso, d.h. vor Ablauf der TTL würden auch diese ihrerseits keine erneute Auflösung versuchen.
Zudem liegt die Ursache hier aller Wahrscheinlichkeit nach nicht in Pi-hole, sofern Deine Beobachtung (lokales WLAN mit alter IP, mobile Daten zumindest öfter mit neuer) nicht auf die fünf Minuten TTL zurückzuführen sind.
Vielmehr ist der DNS-Server Deines DynDNS-Anbieters der erste DNS-Server weltweit, der von der geänderten IP-Adresse Kenntnis hat. Bevor das alle anderen DNS-Server gelernt haben, kann durchaus Zeit vergehen - mitunter Stunden, seltener sogar Tage, im Minimum aber Deine TTL, wobei manche öffentliche DNS-Server sehr kleine TTLs ignorieren (Deine 300 Sekunden = 5 Minuten sind da schon eher klein, aber immer noch ein akzeptabler Wert).
Ich bin daher sehr zuversichtlich, dass der von Dir beobachtete Unterschied auf die Verwendung unterschiedlicher Upstream-DNS-Server in WLAN und Mobildatennetz zurückzuführen ist.
Durch die von mir vorgeschlagene Konfiguration wird Pi-hole für die Auflösung Deiner DynDNS-Domäne immer den zuständigen authoritativen DNS-Server befragen. Schneller kann kein anderer öffentlicher DNS-Server mitbekommen, wann sich Deine öffentliche IP-Adresse ändert.
Ich würde Dir diese Konfiguration also auf jeden Fall empfehlen, unabhängig davon, ob die Propagation gerade wieder einmal zeitnah funktioniert hat oder nicht.
Dann würde mich die der Vollständigkeit halber für meine "Kochrezepte" trotz allem interessieren
Die ist tatsächlich recht niedrig. Jedoch nutze ich zum Updaten ein Skript das von einem Mitarbeiter meines Anbieters ist (aus dem Forum) und das war tatsächlich die Standard-TTL dort. Habe ich also nicht geändert. Es funktioniert ja eigentlich auch ganz gut soweit.
Dem möchte ich nicht widersprechen.
Das leuchtet ein. Jedoch bin ich so gut es geht auf Zensurfreiheit und Log-Freiheit aus.
Die Upstream-DNS die ich nutze (über meine FritzBox mit DNSSEC) gewährleisten das.
Dem DNS von meinem Anbieter würde ich das jetzt nicht guten Gewissens unterstellen können.
Sprich: Auch wenn ich diesen DNS nur für meine Domain nutzen würde, so würde ich diese Spuren eben schon hinterlassen.
Halte mich ruhig für verrückt
Aber es ist zumindest an dieser Stelle technisch (ohne Logging) nicht möglich diesen DNS Eintrag zuverlässig neu aufzulösen. Das leuchtet mir ein, dass der DNS meines Anbieters theoretisch die beste Wahl wäre.
Da sagst du was. Es schien dieses Mal einfach ein Problem beim Anbieter zu sein.
Dieser hatte laut Support in den letzten Tagen Wartungsarbeiten an der entsprechenden Registry und verursachte damit höchstwahrscheinlich dieses Phänomen.
Nun ist ja alles wieder gut
