Du brauchst normalerweise nur eine eingehende UDP-Regel mit Source-Port 53 für die Antworten auf die Anfragen von unbound.
Ich würde bei Regel 19 Source-Port 53 ergänzen und die anderen drei unbound-Regeln entfernen. Die Destination-Ports einzugrenzen macht auf jeden Fall auch Sinn und der Bereich passt ja wohl zu dem, was Du in unbound konfiguriert hast.
Genau, mit forward-zone liefert docker compose exec postfix-mailcow dig AAAA mail.protection.outlook.com @172.22.1.254 NOERROR zurück.
Hattest Du denn dem dig-Aufruf für den unbound-Container auch explizit unbound als Resolver mitgegeben?
Habe ich jetzt auch gerade erst gesehen. Du brauchst normalerweise nur eine eingehende UDP-Regel mit Source-Port 53 für die Antworten auf die Anfragen von unbound.
Du meinst die eingehenden TCP, oder?
Ja, laut Screenshot hast Du ja nur eingehende Regeln. 
Das funktioniert auch nur dann, wenn ich die forward-zone definiert habe.
Ok, also genauso wie beim postfix-Container!?
Wenn ich keine forward-zone in der unbound.conf definiere, funktioniert das Kommando docker compose exec unbound-mailcow dig AAAA mail.protection.outlook.com und liefert "NOERROR" zurück.
Wird dabei denn unbound für den Lookup verwendet oder der Resolver des Container-OS (kenne mich mit Docker nicht aus)? Du könntest dem dig-Aufruf ja mal explizit mitgeben, unbound zu verwenden.
Die beiden TCP-Regeln für unbound sollten in Deiner FW-Policy nicht nötig sein, da die FW für ausgehende TCP-Pakete stateful ist.
(Falls Du keine FW-Regel für NTP hast, solltest Du die ggf. auch noch ergänzen.)
Hast Du das Problem denn nur mit der outlook-Domain oder auch mit anderen? Falls nur die outlook-Domain betroffen ist, könnte es ggf. sein, dass die verantwortlichen Nameserver (direkte) Anfragen Deines Servers blockieren.
Diesmal hat es aber eine andere Ursache: "Maximum connections for host/user reached".
Laufen die Backups beider Server zur selben Zeit, so daß dadurch evtl. gelegentlich zuviele gleichzeitige Verbindungen zum Backup-Server aufgebaut werden?
Wenn ich jemals Gem-Aktualisierungen vornehmen möchte, müsste ich mir einen entsprechenden Docker oder eine VM aufbauen, in der ich den Build mache.
Kannst Du denn ohne das zu machen, Security-Updates einspielen?
Ich kenne Ruby on Rails nicht, habe aber gerade gelesen, dass Rails 7.2.x nur noch bis zum 9. August Security-Updates bekommt. Dann müsstest Du ja jetzt schon auf eine neuere Version gehen?
Wie habt ihr eure Firewall für ausgehenden Traffic konfiguriert?
Ich versuche immer alles soweit wie möglich dicht zu machen. Daher habe ich je nach Server-Profil verschiedene Policies für ausgehenden Traffic.
Beipiel: Alle Server dürfen die (IP-Adressen der) verwendeten Update-Mirror via HTTPS erreichen. Für andere HTTP(S)-Ziele gibt es bei Bedarf weitere Policies für einzelne Server.
Der DNS-Port ist z. B. nur für meinen eigenen rekursiven DNS-Resolver für beliebige Zieladressen freigegeben. Andere Server benötigen diese Policy nicht und können den Port daher nicht anfunken bzw. nur für die konfigurierten DNS-Resolver (die von netcup können ja sowieso immer erreicht werden).
Danke für das Tool und teilen des Quell-Codes! Ich selbst benötige es aktuell zwar nicht, weil ich u. a. SSH nur via IPv6 verwende und sich mein IPv6-Präfix i. d. R. nicht ändert. Aber es ist immer interessant zu sehen, wie sowas umgesetzt wurde und kann ja evtl. auch mal als Inspiration für eigene Implementierungen dienen.
Hier ist übrigens etwas Ähnliches zu finden: Firewallregeln mit dynamischer Home-IP über API updaten
Eine kleine Anmerkung zur Doku:
By default IPv4 is required and IPv6 is a bonus. That fails outright on a DS-Lite connection, which has no public IPv4 at all.
Bei einem DS-Lite-Anschluss hat man auch eine öffentliche IPv4-Adresse (sonst wäre es ja kein Dual-Stack). Man teilt sich diese Adresse aber mit anderen Kunden des ISP (via CGNAT). Daher würde ich es eher als Empfehlung formulieren, in diesem Fall nur IPv6 zu verwenden und beschreiben, warum es ggf. sinnvoll ist.
Solange du nur ACCEPT Regeln hast und nicht wenigstens einen DROP ist alles erlaubt, bis auf die impliziten Regeln z.B. für SMTP von netcup selbst.
Erst mit der ersten netcup Firewall Policy also Richtlinie, die auch was verbietet, wird automatisch auch der Rest auf nicht erlaubt gesetzt.
Die implizite Regel wird auf DROP gesetzt, sobald man eine eigene Regel für die entsprechende Richtung hinzufügt - egal, ob die Regel ACCEPT oder DROP verwendet.
So steht's in der Hilfe:
Die impliziten Regeln können weder entfernt noch bearbeitet werden. Standardmäßig sind sie auf ACCEPT ANY eingestellt. Sobald du jedoch eine eigene eingehende Regel anlegst, ändert sich die implizite eingehende Regel automatisch auf DROP. Das gleiche Verhalten gilt für ausgehende Regeln. Hintergrund: Ohne diese automatische Umstellung würden trotz definierter Regeln weiterhin sämtliche Verbindungen erlaubt, sodass die Firewall-Regeln wirkungslos wären.
Also meine .ch Domains wurden letztens Zwangsmigriert...
Dann ist der Text auf der netcup-Seite wohl nicht mehr aktuell. Wurdest Du über die Migration (vorab) informiert?
Werden die alten Domains auch umgestellt oder bleiben die so? Habe in dem Artikel dazu nichts gelesen
Steht unter Punkt 1:
“Bestehende Domains sind von dieser Änderung vorerst nicht betroffen. Eine Migration für Bestand-Domains befindet sich derzeit in Entwicklung und die Bestand-Domains werden dann nach und nach in das neue System migriert.“
Was ist das denn für eine neue Funktion bei den Domains?
Siehe hier: https://www.netcup.com/de/helpcenter/…omain/cloud-dns
Zusätzlich wäre es toll, wenn man Adresslisten separat definieren und in Regeln referenzieren könnte, so daß man sie nur einmal pflegen muss.
Ich wollte gestern Nachmittag noch zwei Domains umziehen, habe aber nicht damit gerechnet, daß es solange dauert, bis ich die Authcodes bekomme (sind immer noch nicht da). Wieder was gelernt. Na ja, ich hoffe mal, daß es in diesem Jahr noch eine weitere Aktion geben wird.
Ich denke, Du findest die Antwort hier: RE: Das längste Thema
Ich kenne Keyhelp nicht, aber so wie ich es verstanden habe, wird zunächst das Backup gemacht und danach die Bereinung. Wenn beides über SFTP läuft und nur die Bereinigung fehlgeschlagen ist, sollte es kein Firewall-Problem sein.
aber der Beitrag schon im Status "Erledigt" - vermutlich durch Foren-Automatismus
Ja, das wurde wohl automatisch gemacht - ich habe es nun wieder auf "unerledigt" gesetzt. Danke für den Hinweis!
dass ich auch im Browser Desktop Modus keinen direkten Link in der Navigation o.Ä. zum Blog gefunden hab
Argh, die Desktop-Seite ist nun anscheinend genauso wie die mobile Seite aufgebaut und es gibt dort nun auch nur noch ein Hamburger-Menü statt einer dauerhaft eingeblendeten Menüzeile. 
Das ist nicht benutzerfreundlich! In der Desktop-Version ist doch so viel Platz für das Menü. Wenn ich die Seite hier aufrufe, ist sie im Prinzip leer und ich muss nach unten scrollen, um den ersten Text zu sehen. Und man kann nicht mehr einfach auf einen Produktlink wie z. B. "Domains" klicken, sondern muss erst einmal das Hamburger-Menü anklicken. Oh Mann.
Aber das erklärt wohl, warum der Blog-Link nun auch nicht mehr in der Desktop-Version vorhanden ist.
netcup-seite.png
