Eigener Resolver für mehrere RS und VPS im Cloud vLan (Free)

  • Ich habe mir einen kleinen Resolver (Ubuntu 22.0.4) für Server (Debian 11) im Cloud vLAN auf Basis von Unbound aufgesetzt. Auf zwei älteren Servern (S1, S2), die durch Upgrades auf Debian 11 gebracht wurden, ist sysmd-resolved nicht aktiv und die Nameserver (Resolver) werden direkt in der /etc/resolv.conf festgelegt. Ich trage da die vLAN-IP (v4 und v6) des eigenen Resolvers ein. Zusätzlich noch einen der Resolver von Google oder Cloudflare für den Fall, dass mein Resolver mal down ist. Das klappt prima, die benutzen seit mehreren Tagen ununterbrochen den ersten Nameserver aus der /etc/resolv.conf, die IPv4 meines Resolvers. Also wie geplant.


    Jetzt zum Problem: Die beiden anderen Server benutzen systemd-resolved. Hier habe ich den Stub-Resolver erst mal aktiv gelassen und in der /etc/systemd/resolved.conf die selben Nameserver in der selben Reihenfolge eingetragen. Auch das funktioniert dann einige Stunden oder einen halben Tag lang einwandfrei. Auch diese Server schicken ihre DNS Queries per IPv4 über das Cloud vLAN an meinen Resolver. Irgendwann löst dann z.B. Postfix eine Query für den PTR eines Möchtegern-Spammers aus und Unbound stellt fest, dass die Daten nicht valide sind und gibt den Status SERVFAIL zurück. Passiert das öfter (und Spammer haben die unangenehme Eigenschaft, nicht so schnell aufzugeben. In diesem Fall vielleicht sogar gezielt, um den unangenehmen Resolver loszuwerden), dann wird der Resolver gewechselt, irgendwann lande ich dann unweigerlich bei Google/Cloudflare. Das möchte ich möglichst vermeiden, außer es geht eben wirklich nicht anders.


    Würde es helfen, den Stub-Resolver abzuschalten in der /etc/systemd/resolved.conf und den Symlink /etc/resolv.conf entsprechend umzustellen oder deaktiviert man besser gleich den systemd-resolved komplett? Ich stelle immer mehr fest, dass ich noch zu wenig darüber weiss und das Internet auch nicht viel schlauer ist als ich. Zwei Quellen ergeben drei unterschiedliche empfohlene Vorgehensweisen. Oder ist es besser, den Unbound so einzustellen, dass er bei nicht validierenden RRs niemals SERVFAIL zurückgibt, die Bogusdaten an den Client schickt und nur da ad-Flag nicht setzt? Das ist natürlich ein Risiko, wenn der Client die invaliden Daten benutzt. Dass systemd-resolved da empfindlich reagiert und von eingeschränkten Fähigkeiten des Resolvers ausgeht, ist bekannt, es gibt diverse Issues dazu auf Github, manche davon nach vielen Jahren immer noch offen.

  • Ich habe ein ganz ähnliches Szenario, nur läuft der unbound bei mir in einem Container und versorgt meine anderen Container und VLAN Hosts.


    Ich stelle immer mehr fest, dass ich noch zu wenig darüber weiss und das Internet auch nicht viel schlauer ist als ich.

    Die Erfahrung habe ich auch gemacht. Ähnlich wie du hatte ich als Fallback öffentliche DNS Server konfiguriert. Dann habe ich festgestellt, dass je nach benutztem DNS Client das Verhalten komplett unterschiedlich ist. Einige wechseln im Fehlerfall, andere scheinen die Anfragen nach einem spezifischen Algorithmus auf alle konfigurierten DNS Server zu verteilen. Das Verhalten war nicht deterministisch, jedenfalls konnte ich kein Muster erkennen. Letztlich habe ich keine gute Lösung gefunden. Da muss man wahrscheinlich spezifisch für jeden Anwendungsfall und DNS Client draufschauen.

  • Ich habe ein ganz ähnliches Szenario, nur läuft der unbound bei mir in einem Container und versorgt meine anderen Container und VLAN Hosts.


    Die Erfahrung habe ich auch gemacht. Ähnlich wie du hatte ich als Fallback öffentliche DNS Server konfiguriert. Dann habe ich festgestellt, dass je nach benutztem DNS Client das Verhalten komplett unterschiedlich ist. Einige wechseln im Fehlerfall, andere scheinen die Anfragen nach einem spezifischen Algorithmus auf alle konfigurierten DNS Server zu verteilen. Das Verhalten war nicht deterministisch, jedenfalls konnte ich kein Muster erkennen. Letztlich habe ich keine gute Lösung gefunden. Da muss man wahrscheinlich spezifisch für jeden Anwendungsfall und DNS Client draufschauen.

    Ich werde jetzt erst mal die SERVFAIL Antworten von Unbound loggen und erklären lassen, da gibt es ja eine Einstellung dafür. Dann schaue ich mir an, was andere, öffentliche Resolver mit der selben Anfrage machen, ob da also auch ein SERVFAIL kommt oder vielleicht nur NXDOMAIN oder gar einfach die unsicheren Daten herausgegeben werden. Dann muss ich weitersehen, eventuell mal Stub-Resolver aus, um herauszufinden ob das mit den Forwardern der Stub-Resolver regelt oder ob das ein Ding von systemd-resolved ist. Den Stub-Resolver habe ich bisher laufen lassen, weil es erstens einfach ist, den eigenen Resolver da als ersten Forwarder einzubinden und zweitens, weil damit auch lokal gecacht wird und somit weniger Anfragen zu meinem Resolver kommen und außerdem der lokale Cache wahrscheinlich doch nochmal schneller ist als die Abfrage übers vLAN, auch wenn Unbound die Antwort aus seinem Cache nimmt.


    In den letzten 2 Stunden scheint nichts passiert zu sein, alle DNS Queries gehen derzeit noch an meinen Resolver.

  • Ich muss mir das nachher noch genauer anschauen, muss jetzt erst mal einkaufen. Auf den ersten Blick sieht es so aus, als ob da jede Menge Queries reinkommen für "105.184.in-addr.arpa. SOA". Muss ich nacher mal schauen auf den entsprechenden Maschinen was da los war, wenn ich die Anfrage an Cloudflare stelle kommt auch

  • Würde den Ansatz mit einem zentralen Resolver einfach komplett bleiben lassen und auf jeden einzelnen Server einen eigenen Recursive Resolver packen. Die zusätzlichen Ressourcen sind egal und alle Systeme funktionieren unabhängig.


    Dedizierte Resolver zu betreiben macht nur Sinn, wenn man einen riesigen Fuhrpark an Maschinen hat oder eigene Zonen betreiben will. Und bei eigenen Zonen würde ich tatsächlich trotzdem einen je einen Recusive Resolver auf jedes System packen und dann diese eigenen Zonen Forwarden+Cachen oder echt via AXFR replizieren.


    So ist es auch nicht schlimm wenn der eigene Primary NS mal ein paar Tage kaputt ist.


    Das entspannt die ganze Geschichte erheblich, und sorgt bei einer Störung oder VM Wartung seitens netcup nicht dafür, dass 10 andere VMs kaputt sind.


    Bei Interesse kann ich ein Ansible Playbook für einen Recursive Resolver auf bind9 Basis teilen.


    Das Eintragen von Backup Nameservern ist auch suboptimal, weil dann bei Nichterreichbarkeit des primären Servers im schlimmsten Fall die DNS Queries ultra lange dauern.

  • z.B. Postfix eine Query für den PTR eines Möchtegern-Spammers aus und Unbound stellt fest, dass die Daten nicht valide sind und gibt den Status SERVFAIL zurück

    Die Fehler beim Auflösen von PTR Records sind bei mir seit Abschaltung des Stub-Resolvers verschwunden.

  • bind9 läuft da eh schon drauf, aber authoritativer Server und recursive resolver gleichzeitig ist suboptimal. Und mit Unbound gäbe es wohl ein Problem, wenn beide Port 53 benutzen oder wie würde man das dann einstellen? Bind9 komplett entsorgen und durch Unbound zu ersetzen würde das verwendete Keyhelp Serverpanel wahrscheinlich auch nicht gerade erfreut zur Kenntnis nehmen. Aber ich schaue mal was sich machen lässt am augenblicklichen Setup. Ohne systemd-resolved klappt es erwiesenermaßen sehr zuverlässig.


    Edit: Ich habe jetzt auch den Stub-Resolver ausgeschaltet in der /etc/systemd/resolved.conf. Danach mit systemctl restart systemd-resolved.service den Service neu starten, dann kann man mit ln -f -s /run/systemd/resolve/resolv.conf /etc/resolv.conf den Symlink ändern. So werden dann die im /etc/systemd/resolved.conf eingestellten DNSServer benutzt. Ich habe da meinen im vLAN an erste Stelle gesetzt. Der wird auch immer als erster aufgerufen, da hat jetzt seit einem Tag nichts mehr gewechselt. Allerdings ist mir aufgefallen, wenn der erste Nameserver mal zu lang braucht, dann wird die Anfrage an den nächsten geschickt usw. Gemerkt habe ich das, weil ich die IPv6 meines Resolvers als zweiten Resolver eingetragen hatte und somit die gleiche Anfrage über IPv4 und IPv6 reinkam, wonach dann zwar beide Anfragen beantwortet wurden, aber zwei Anfragen an den selben Resolver zu schicken erscheint mir nicht besonders sinnvoll, auch wenn es in diesem Fall durchaus funktioniert hat. Das passiert auch nur sehr selten bei ungewöhnlich langen Antwortzeiten (ca >5s) des Unbound Resolvers, habe ich jetzt bisher nur einmal beobachtet. DNSSEC habe ich jetzt mal ganz frech auf "yes" gesetzt, funktioniert bisher in etwa so, wie ich es wollte. Nur einen lokalen Cache habe ich jetzt nicht mehr, aber die Antwort kommt in dem Fall sehr schnell von meinem Resolver, der sie dann ja auch im Cache hat.


    Ich beobachte das jetzt mal ein paar Tage, ob es irgendwelche Auffälligkeiten gibt. Ansonsten bleibt als letzte Alternative doch noch eine lokale Unbound-Installation übrig. In der derzeitigen Konfiguration von systemd-resolved könnte das eventuell relativ problemlos klappen.