Dynamic DNS aktualisiert nicht mehr
-
@jensano
Das eigentliche Problem scheint gleich in der ersten, also chronologisch in der letzten Zeile zu stehen: freedns.afraid.org kann nicht aufgelöst werden.Warum? Hast du auch DNSBL aktiv?
DNSBL hat auch eine "Custom Domain Whitelist". Wenn das bei dir läuft, kannst ja mal versuchen, freedns.afraid.org da einzutragen.
Warum da aber blockiert würde, wäre mir nicht klar. -
@jensano said in Dynamic DNS aktualisiert nicht mehr:
Mit dem pfBlocker hatte ich in letzter Zeit DNS Dienste geblockt, so dass Clienten nicht mehr selber DNSoverHTTPS nutzen können, sondern über meinen Resolver müssen
Oke, hier ist eine Umleitung für DNS Request auf localhost beschrieben, dann brauchst nichts blocken.
Es sieht so aus, dass der DNS Resolver nicht startet bei aktivierten pfBlocker, mal checken. Eventuell irgend ne Konfig verkorkst.
-
Es scheint als ob er Anfangs Schwierigkeiten hat mein Resolver. Wenn ich ja selber einen Refresh des DYN DNS Dienstes später anschiebe dann funktioniert es. Erkennen tut er ja bei einem WAN Reconnect das sich die IP geändert hat und versucht den DYN DNS Dienst zu aktualisieren. Kann man den Resolver irgendwie separat neu installieren und komplett resetten? Ich such danach aber finde noch nichts. Ich nutze bei mir die Quad 9 Server per Forwarding im Resolver mit DNSSEC und DNS over TLS. Das funktioniert alles gut. Nur halt kurz am Anfang gibt es da irgendwelche Probleme. Genauer kann ich die Logs nicht deuten.
P.S.
Mit den Infos in dem Link wird erstmal nur DNS über Port 53 auf die pfSense umgeleitet. Das habe ich bei mir übrigens auch konfiguriert. Der Link unten in dem Artikel beschreibt aber noch andere Wege die ich bei mir auch umgesetzt habe. So musst du auch DNS über Port 853 also DNS over TLS per Portforwarding auf die pfSense umleiten. Ja und wenn wir dann zu DNS over HTTPS kommen, dann gehts über Port 443. Da ist dann Schluss mit Portforwarding. Da kann man nur die ganzen DNS Dienste für die Clienten blocken. pfBlocker hat da extra Listen zu. Seit dem kann ich auch, wegen dem Logging der Anfragen, sehen wer sich alles über DNS over HTTPS rausmogeln will. Das ist z. B. Mein Robistaubsauger von Xiaomi. Auch mein iPad sehe ich ab und zu in der Liste. Irgendeine App darauf will das also auch machen. Denn das kann jede App quasi selber entscheiden welchen weg sie gehen will.
Deswegen Portforwarding von Port 53 und 853 und blocken aller DNS Dienste per pfBlocker. -
@jensano
Schau mal ins Resolver Log, vielleicht verrät dir das woran es scheitert.Die Zeilen aus dem System Log würde ich mal so interpretieren: Beim Versuch das DynDNS Update durchzuführen kann freedns.afraid.org nicht aufgelöst werden. Das DynDNS Update schlägt fehl und pfSense starten den gesamten Prozess neu, wozu auch ein Start des Resolvers gehört (gestoppt wird er sofort, nachdem die alte WAN-IP weg ist). Weil dieser aber bereits läuft, wird der Fehler in Zeile 2 geloggt.
Heißt für mich, der Resolver läuft zwar, aber dennoch können Namen nicht aufgelöst werden, er ist eventuell noch nicht bereit. Hinweise auf die Ursache könnten sich im Resolver Log finden.
-
@viragomann
Leider verrät mir das nichts. Was aber nicht heisst, dass es da keine Infos gibt. Siehe Log unten.Was ich noch versucht habe:
Über "Diagnostics / Command Prompt / Execute Shell Command" den Befehl "/etc/rc.dyndns.update" ausgeführt. Da ich den ja erst separat zu den ganzen Automatischen Aktionen ausführen kann die bei einem Reconnect ablaufen, funktioniert dies. Die Cached Dynamic DNS IP wird sofort grün.Es sieht einfach so als das der Befehl zu früh ausgeführt wird. Da ist der Resolver noch nicht bereit die Adresse zu bearbeiten. Theoretisch müsste doch die pfSense bevor sie solch einen Befehl raushaut (und das auch nur einmal versucht) auf den Resolver warten bis der sagt "ich bin einsatzbereit"
-
@jensano
Eine Ursache für das Problem kann ich in dem Log auch nicht erkennen. Es offenbart aber, dass der Start des Resolvers 20 Sekunden dauert, was normalerweise in der Sekunde passiert. Erhöhe den Log Level des Resolvers mal auf 2, vielleicht sieht man dann Hinweise auf Ursachen für die Verzögerung.
Ein System-Log vom gleichen Zeitabschnitt wäre ebenfalls hilfreich.Die Systemlast ist im normalen Bereich?
-
@jensano said in Dynamic DNS aktualisiert nicht mehr:
So musst du auch DNS über Port 853 also DNS over TLS per Portforwarding auf die pfSense umleiten. Ja und wenn wir dann zu DNS over HTTPS kommen, dann gehts über Port 443. Da ist dann Schluss mit Portforwarding. Da kann man nur die ganzen DNS Dienste für die Clienten blocken. pfBlocker hat da extra Listen zu. Seit dem kann ich auch, wegen dem Logging der Anfragen, sehen wer sich alles über DNS over HTTPS rausmogeln will. Das ist z. B. Mein Robistaubsauger von Xiaomi. Auch mein iPad sehe ich ab und zu in der Liste. Irgendeine App darauf will das also auch machen. Denn das kann jede App quasi selber entscheiden welchen weg sie gehen will.
Deswegen Portforwarding von Port 53 und 853 und blocken aller DNS Dienste per pfBlocker.Jupp, danke für die Info. Nutze DNS over TLS nur von der pfSense zu den DNS Servern, intern UDP 53 only. Werde das mal beobachten, wo wer sich vorbeimogelt. :)
-
@mike69 said in Dynamic DNS aktualisiert nicht mehr:
Jupp, danke für die Info. Nutze DNS over HTTPS nur von der pfSense zu den DNS Servern, intern UDP 53 only.
Du nutzt DoT, nicht DoH.
-
@bob-dig said in Dynamic DNS aktualisiert nicht mehr:
@mike69 said in Dynamic DNS aktualisiert nicht mehr:
Jupp, danke für die Info. Nutze DNS over HTTPS nur von der pfSense zu den DNS Servern, intern UDP 53 only.
Du nutzt DoT, nicht DoH.
Damned, stimmt. :)
korrigiert.
-
@viragomann
Den Log Level auf 2 erhöhen produziert etliche Einträge, so schnell kann ich das Log gar nicht filter.Ich habe aber mal ein Logvergleich vom Resolver und General gemacht. Der Eintrag "Start of Service Unbound" und "Could not resolve host..." kommt zur gleichen Sekunde.
Es dauert aber immer noch 26 Sekunden bis der Resolver wieder da ist. Ist der bei dir echt in Sekunden wieder da? Das General Log ist zu lang um es hier reinzustellen.Ich bekomme zwar weiterhin die gleichen Logeinträge, aber nun funktioniert meine Aktualisierung vom DYN Dienst wieder. Ich habe dazu im Resolver folgende Funktion deaktiviert:
Das ist reproduzierbar mit dem DYN DNS: Haken drin=Geht nicht. Haken raus=geht.
Kann das wer von euch mal testen ob das bei euch auch so ist?Resolver
-
@jensano said in Dynamic DNS aktualisiert nicht mehr:
Den Log Level auf 2 erhöhen produziert etliche Einträge, so schnell kann ich das Log gar nicht filter.
Kommt mir bekannt vor. Level 1 ist default, 2 total aggressiv. Die höheren Levels traut man sich gar nicht anzutasten. In der GUI mit 200 Zeilen siehst du da nur noch Sekunden. Die Log-Files sind aber länger. Das Resolver Log findest du in /var/log/unbound.log.
@jensano said in Dynamic DNS aktualisiert nicht mehr:
Das ist reproduzierbar mit dem DYN DNS: Haken drin=Geht nicht. Haken raus=geht.
Kann das wer von euch mal testen ob das bei euch auch so ist?Den Haken habe ich auch gesetzt. Dennoch startet der Resolver in einer Sekunde.
Mit DynDNS habe ich auch kein Problem, habe auch eine FreeDNS Konfig.
Aber soweit ich mich erinnere, ist @JeGr ein vehementer Gegner dieser Funktion. Er sollte wohl beantworten können, warum.
Aus Threads hier habe ich nur mitbekommen, dass es häufige unbound Neustarts verursacht, immer wenn ein neuer DHCP-Lease ausgestellt wird. -
@viragomann said in Dynamic DNS aktualisiert nicht mehr:
Aber soweit ich mich erinnere, ist @JeGr ein vehementer Gegner dieser Funktion. Er sollte wohl beantworten können, warum.
seufzt
Ich bin kein "vehementer Gegner dieser Funktion", sondern habe schlicht mehrfach zitiert und darauf hingewiesen, dass bei aktivem Haken von "Register DHCP Leases" es zu einem ständigen Neustart von Unbound kommt, weil jedes Gerät mit dynamischer IP sobald es per DHCP nen neues Lease bekommt oder aktualisiert eine Rückmeldung an Unbound gibt und der dann NEU STARTET um die aktuelle Liste an Clients zu kennen. Zudem gibt es keinen sinnvollen Grund einen rando dynamischen Client mit rando Name einfach in den DNS zu pumpen. Weshalb sollte ich den Namen von der Kiste brauchen? Und wenn jetzt einer sagt, weil er da mit RDP, SMB, CIFS oder sonstwas drauf muss, dann ist das kein "Client" Job, sondern ein Server/Service Job. Und dann bekommt sowas ne statische oder zumindest reservierte (semi statische) IP (via DHCP/MAC) und die werden einmalig beim Starten eingelesen und benötigen logisch keinen ständigen Neustart von Unbound.
Bei genug Clients und vielen Änderungen im DHCP hat man Unbound dann ständig am Neustarten weil es alle paar Sekunden/Minuten nen Client gibt, der das Ding zum Neustarten bringt. Darum macht man es aus. Es sollte mal via Reload gelöst und angesteuert werden, da gab es aber einen Regression Bug und ein Problem mit Unbounds neuer Python Module Integration. Daher ist das in 2.5 immer noch drin.
https://redmine.pfsense.org/issues/5413
tl;dr:
DNS Resolver:
- disable DHCP Registration von irgendwelchen rando Clients
- disable DHCP Registration von irgendwelchen rando OpenVPN Clients
wenn notwendig: - enable DHCP static lease Integration ins DNS. Da wird nur ein Neustart fällig wenn man neue DHCP Mappings erzeugt.
