DNS-Resolver funktioniert nach einiger Zeit nicht mehr
-
Hallo zusammen,
Ich habe mittlerweile 4 pfsense-Instanzen, bei denen seit Jahren und verschiedenen Versionen immer folgender Fehler auftritt:
Der DNS-Resolver funktioniert nach einiger Zeit (Tage, Wochen) nicht mehr. D.h. die lokalen Clienst (per DHCP tlw. auch mit fester IP) können keinen Namensauflösung mehr durchführen, die Internet-Verbindung funktioniert aber. Stelle ich den Client auf externe Nameserver um, dann funktioniert der Client wieder.
Als Nameserver wird quad-9 oder quad-1 genutzt. Die Clients nehmen als Nameserver die pfsense.
Hardware:
- 2x virtualisiert (KVM, Proxmox)
- 1x APU-Board
- 1x Siemens-MINI-PC
Reboot der jeweiligen PFsense reicht, dann funktioniert die Internetverbindung wieder für einige Zeit. Die PFsensen laufen entweder auf einer Public-IP oder selbst als Client hinter einem weiteren Router.
Hat jemand eine Idee, was das sein könnte?
Gruß,
Bytegetter -
Hallo!
@bytegetter said in DNS-Resolver funktioniert nach einiger Zeit nicht mehr:
Als Nameserver wird quad-9 oder quad-1 genutzt.
Das hast du im Resolver konfiguriert, oder nur in den General Settings der pfSense?
Der Resolver würde dann eigentlich im Forwarding-Mode arbeiten.Im Log könnten sich Hinweise zum Problem finden. Im System Log sollte der Ausfall von unbound verzeichnet werden. Dann wären die Einträge des DNS Logs zu diesem Zeitpunkt interessant.
Ich hatte solche Probleme mal mit älteren Versionen (2.4.x), weiß aber gar nicht mehr, was da die Lösung war.
Ich nehme an, du sprichst hier von aktuellen Versionen? -
Am Resolver habe ich bisher noch nichts geändert, dass sind die Originaleinstellungen. Ich musste auch erst mal gucken, wie das bei der pfsense heisst.
Der DNS selbst funktioniert. Ein Client mit dem gleichen DNS hat keine Probleme. Ein Muster ist auch nicht erkennbar. Manchmal funktioniert das über Monate, manchmal tritt der Fehler bei der gleichen pfsense 3 mal am Tag auf.
Versionen ist jeweils die aktuelle oder die Vorversion.
Bei der ältesten pfsense (auf APU-Board) tritt der Fehler gefühlt häufiger auf. Die ist aber mittlerweile seit 4 Jahren in Betrieb mit allen Updates, hat aber auch die meissten Clients und Updates.
Bevor ich anfange die pfsense-Installationen zu ersetzen wollte ich zumindest versuchen den Fehler zu finden. ;)
Auf den pfsense-VMs gab es am Anfang Probleme mit der RAM-Ausstattung. Irgendwann sind die Nachts mal vollgelaufen, 768MB sind aber aktuell ausreichend. Im Allgemeinen brauchen die nicht mehr als 80-90MB RAM. Ich habe aber nicht herausgefunden, ob da Nachts irgendwelche Cron-Jobs laufen, die so viel brauchen. Bei 512MB tratt das Problem nur noch alle paar Monate, mit 768MB gar nicht mehr auf.
-
@bytegetter said in DNS-Resolver funktioniert nach einiger Zeit nicht mehr:
@viragomann
Am Resolver habe ich bisher noch nichts geändert, dass sind die Originaleinstellungen.Dann verwendet er auch nicht quad-9 oder quad-1. Das wäre nur im Forwarder Mode der Fall.
Standardmäßig verwendet er ein Liste von Root-Servern.Das einzige, was mir einfällt, was den Resolver "nervt", ist häufige Registrierung von DHCP Clients. "DHCP Registration" in den Einstellungen. Falls gesetzt, kannst du diesen Haken mal wegnehmen.
Aber wie gesagt, ansonsten könnten die Logs hilfreich sein.
-
@viragomann said in DNS-Resolver funktioniert nach einiger Zeit nicht mehr:
Das einzige, was mir einfällt, was den Resolver "nervt", ist häufige Registrierung von DHCP Clients. "DHCP Registration" in den Einstellungen.
Mir fällt da noch mehr ein, siehe: https://forum.netgate.com/topic/170235/unbound-massively-broken-pfsense-2-5-2
Wenn mir jemand erklären könnte, wie ich den Patch, der das Problem wohl beheben soll, via System Patches eingespielt bekomme, wäre ich sehr dankbar.
-
@thiasaef Worauf zielt denn die Frage ab? Also was ist das Problem, den Patch in "System Patches" einzutragen? Das Paket hat ja eine kleine Doku und jetzt nicht gerade viele Einstellungen und im Normalfall wird nichts anderes als nen Namen/Description und die ID des Patches gebraucht.
https://docs.netgate.com/pfsense/en/latest/development/system-patches.htmlAber als kleine Anleitung für alle die sich damit vllt noch nicht beschäftigt haben, es ist extrem simpel:
- System Patches Package installieren
- Neuen Eintrag erstellen
- Beliebige Description reinschreiben, die man hinterher auch erkennt ;)
- Bspw.: [2.5.x+] GW failback regression fix
- Commit ID: Die ID aus dem Ticket rein, also ec73bb89489d830ec21c4e04ffa3ec401791b55d
- Speichern (das wars schon!)
- Fetch drücken (holt den Patch, die Felder werden dann alle automagisch ausgefüllt)
- Test drücken: sollte anzeigen, dass der Patch angewendet aber nicht entfernt werden kann (wie auch ;))
- Apply drücken
- Fertig
- Wer nochmal Test drückt, sieht jetzt, dass der Patch jetzt entfernt, aber nicht angewendet werden kann - somit kann er also via Revert zurückgerollt werden.
That's it :)
-
@jegr said in DNS-Resolver funktioniert nach einiger Zeit nicht mehr:
@thiasaef Worauf zielt denn die Frage ab? Also was ist das Problem, den Patch in "System Patches" einzutragen?
Das Problem ist, dass nach "Fetch drücken", kein Test bzw. Apply Button erscheint.
Eine erste Vermutung wäre, dass das Modul nicht selbstständig andere Patches, von denen dieser Patch eventuell abhängt, mitinstalliert.
Außerdem würde ich mir wünschen, dass Patches wie dieser zeitnah in die Liste der empfohlenen Patches mit aufgenommen würden.
-
@thiasaef Bei mir funktioniert es, also scheinst du entweder nen Fehler zu haben/machen oder dein DNS läuft ggf. nicht korrekt? Was sagen denn Logs o.ä.?
Ich hab das gerade genauso wie oben beschrieben bei meinen Testkisten reingeworfen, fetch, apply, fertig.
-
@jegr said in DNS-Resolver funktioniert nach einiger Zeit nicht mehr:
Was sagen denn Logs o.ä.?
Mar 1 15:12:03 php-fpm 81172 System Patches: Patch fetched successfully (ID: 621e29b113814, DESCR: Always restart gateway monitoring and services on interface UP/START event (Redmine #11570))Edit: Der Witz wird wohl sein, dass du im Gegensatz zu mir noch auf 2.5.2 bist.
-
@thiasaef Da du pfSense 2.6.0 nutzt, hast du schon die aktuelle System_Patches Version 2.0_3 installiert?
-
@nonick nein, aber daran lag es leider auch nicht.
-
Ich bekomm keinen dieser Commits via System / Patches nachinstalliert. Dann bleibt wohl wirklich nur ein Downgrade auf 2.5.2.
-
@thiasaef Man soll auch nicht einfach random irgendeinen Commit installieren.
Die Frage ist ja ob die aktuelle SystemPatches Version mit dem o.g. Commit funktioniert und die Felder ausfüllt nach einem Fetch oder nicht. Das Apply ist ja nochmal nen anderer Punkt.
-
@jegr said in DNS-Resolver funktioniert nach einiger Zeit nicht mehr:
Man soll auch nicht einfach random irgendeinen Commit installieren.
Schon klar, es ging ja erst mal nur darum herauszufinden, ob es sich um einen simplen Merge Conflict handelt, oder ob der Hund wo anders begraben ist.
Die Frage ist ja ob die aktuelle SystemPatches Version mit dem o.g. Commit funktioniert und die Felder ausfüllt nach einem Fetch
Klares nein.
-
@thiasaef OK also hast du Probleme mit dem neuen SysPatch Update 2.x
Dann geh bitte mal so vor:
- wie oben anlegen
- Fetch drücken
- ID sollte sich jetzt zu voller URL geupdated haben, aber das Textfeld ist leer (?)
- URL in einem Browser aufmachen
- Strg+A, Strg+C (alles kopieren was angezeigt wird, sollte nur Text sein und von "From ec7... bis ?> gehen"
- den ganzen Schmodder bei "Patch Contents" einfügen
- Rest so lassen (Strip Count 2, Base /, Ignore Whitespaces)
- speichern
Jetzt sollte Apply/Revert und Test auftauchen. Testen, Apply drücken, gegenprüfen :)
Edit: Patch wohl in Vorbereitung um das zu reparieren: https://forum.netgate.com/topic/170300/new-system-patches-v2-0/16
-
@jegr mit System_Patches 2.0_4 hat es jetzt ohne Umweg über "Patch Contents" funktioniert.
Edit: Der DNS Resolver funktioniert jetzt wieder, aber sauber gelöst ist das Problem damit leider nicht, denn Unbound legt jetzt einen kompletten Neustart hin, sobald ein direkt an der Firewall angeschlossenes Gerät ein oder ausgeschaltet wird.
-
@thiasaef said in DNS-Resolver funktioniert nach einiger Zeit nicht mehr:
Edit: Der DNS Resolver funktioniert jetzt wieder, aber sauber gelöst ist das Problem damit leider nicht, denn Unbound legt jetzt einen kompletten Neustart hin, sobald ein direkt an der Firewall angeschlossenes Gerät ein oder ausgeschaltet wird.
a) was ist daran nicht sauber wenn es funktioniert?
b) was ist ein "an der FW angeschlossenes Gerät"? Normalerweise hängt ne Firewall am Switch und daran ein Gerät.
c) Unbound hatte schon immer ein paar Macken, bei soft-reloads warum man ja lange bei per DHCP-hinzugefügten Namen nen Neustart getriggert hatte um sicher zu sein dass es sauber geladen wird.Aber dass man nen Dienst durchtritt, wenn es ein Interface Event gibt ist jetzt nichts abartig neues. Es gibt eben Dienste die mehr oder weniger gut drauf klarkommen, dass ihr Binding an ein Interface nicht mehr existiert und die dann damit nicht gut umgehen können. Und wenn unbound auf "Interface any" gebunden ist und eines wird runtergefahren (weil Gerät direkt an FW hängt) dann muss ich eben den Service durchtreten damit er das mitbekommt, dass er nicht mehr am Interface hängt. Verstehe da nicht was unsauber daran ist. Natürlich wäre es besser nen online reload schicken zu können, aber es wird ja einen Grund haben, dass ein restart statt einem reload gemacht wird?
-
@jegr said in DNS-Resolver funktioniert nach einiger Zeit nicht mehr:
a) was ist daran nicht sauber wenn es funktioniert?
Unbound ist temporär nicht erreichbar und der DNS Cache geht ebenfalls jedes Mal komplett verloren, ansonsten siehe: https://redmine.pfsense.org/issues/5413
was ist ein "an der FW angeschlossenes Gerät"? Normalerweise hängt ne Firewall am Switch und daran ein Gerät.
In meinem Fall drei Endgeräte, die alle mehrmals am Tag ein- bzw. ausgeschaltet werden.
c) Unbound hatte schon immer ein paar Macken, bei soft-reloads
Wenn es am Zusammenspiel zwischen Unbound und FreeBSD läge, müsste OPNsense genauso betroffen sein. Ist es das?
Aber dass man nen Dienst durchtritt, wenn es ein Interface Event gibt ist jetzt nichts abartig neues.
Ja, wenn es einen Grund dafür gäbe, der nicht "der Weg des geringsten Widerstandes" lautet und außerdem war der Neustart in 2.4.5-p1 ja offenbar auch nicht nötig.
aber es wird ja einen Grund haben, dass ein restart statt einem reload gemacht wird?
Kurz und knapp Faulheit.
-
@thiasaef said in DNS-Resolver funktioniert nach einiger Zeit nicht mehr:
Wenn es am Zusammenspiel zwischen Unbound und FreeBSD läge, müsste OPNsense genauso betroffen sein. Ist es das?
Jetzt neuerdings - ja/jein, vorher nicht, nein. OPNsense hatte nicht FreeBSD als BaseOS drunter, sondern einen "Spezialfork" den sie jetzt im letzten Release rausgenommen haben, weil der Sinn und Nutzen kaum noch gegeben war und die Nachteile wie Warten auf Pakete und Commits zu groß.
@thiasaef said in DNS-Resolver funktioniert nach einiger Zeit nicht mehr:
Unbound ist temporär nicht erreichbar und der DNS Cache geht ebenfalls jedes Mal komplett verloren, ansonsten siehe: https://redmine.pfsense.org/issues/5413
Das stimmt natürlich.
@thiasaef said in DNS-Resolver funktioniert nach einiger Zeit nicht mehr:
Ja, wenn es einen Grund dafür gäbe, der nicht "der Weg des geringsten Widerstandes" lautet und außerdem war der Neustart in 2.4.5-p1 ja offenbar auch nicht nötig.
Doch, war er bereits da schon. Die Implementierung war schon seit 2.4.x mit restart und beim Resolver, dass man keine DHCP Leases hinzufügen sollte da sonst die Neustarts zu häufig laufen.
@thiasaef said in DNS-Resolver funktioniert nach einiger Zeit nicht mehr:
Kurz und knapp Faulheit.
Das ist schlicht ne Unterstellung die niemand was bringt.
-
@jegr said in DNS-Resolver funktioniert nach einiger Zeit nicht mehr:
Die Implementierung war schon seit 2.4.x mit restart
Da muss ich widersprechen. Bei 2.4.5-p1 wurde Unbound definitiv nicht bei jedem
rc.newwanipEvent neu gestartet.Das ist schlicht ne Unterstellung die niemand was bringt.
Stimmt, aber solange mir niemand einen besseren Grund nennt, bleibt das meine Arbeitshypothese.
-
T thiasaef referenced this topic on
-
T thiasaef referenced this topic on
-
T thiasaef referenced this topic on
