Beiträge von Zierleiste

engine Das war nicht meine Frage, dass man die Regeln braucht, ist klar (hat man ja hier schon lesen können).

Meine Frage war, wie das Beispiel in der Hilfe gemeint ist (Kapitel 1. Über die Firewall).

[netcup] Sarah G. Zum Thema DNS:

Bei Verwendung der netcup-DNS-Server werden keine Firewall-Regeln für DNS benötigt, richtig?

Beantworte ich mal selbst: Steht bereits in der Hilfe drin, dass das zutrifft.

Das Beispiel in der Hilfe dient für den Betrieb eines eigenen DNS-Servers und nicht für die Verwendung externer DNS-Server wie beispielsweise 1.1.1.1?

Beides sollte man vielleicht in der Hilfe erläutern.

Edit: Antwort erste Frage nachgetragen.

Wobei die aktuelle Version / der Nachfolger RFC 7208 ist.

Ausführliche Erklärungen finden sich hier: http://www.open-spf.org/FAQ/Common_mistakes/ bzw. http://www.open-spf.org/Introduction/

Ich bezog mich auf meinen Beitrag #19, das war vielleicht nicht ganz klar. Ich hatte ja auch beide Varianten empfohlen.

Ja, hatte ich leider zu spät kapiert

bekenz So eine Zeile hat er ja (Zeile 5).

Gehört der _dmarc-Eintrag nicht immer an die Apex Domain?

Nachtrag: Das hat sich hier blöd überschnitten. Die rot eingerahmte Zeile im Bild in #16 darf nur @ oder den Hostnamen mail enthalten, nicht aber den gesamten Domainnamen.

Letztlich hängt es von deinen E-Mail-Adressen ab: Benutzt Du name@mailrunner.de, dann muss der TXT-Record für SPF bei der Domäne gesetzt werden (also hier mit „@“), wenn deine E-Mails hingegen von name@mail.mailrunner.de kommen, dann eben dort. Es ist nicht schädlich, beide Varianten einzutragen.

Nachtrag: Die Diagnoseseiten arbeiten auch nicht alle korrekt. Früher gab es beispielsweise einen eigenen SPF-Record, der aber von einem TXT-Record abgelöst worden ist. Auch das Durchgreifen auf die Apex Domain machen nicht alle Diagnoseseiten richtig, daher meine Empfehlung, den TXT-Record einfach für beide Varianten zu setzen.

Interessante Fragestellung, die mir einen Anstoß gegeben hat, bei einem ähnlichen Phänomen nochmals etwas tiefer nachzuforschen.

Vielleicht ist es ein Timing-Problem und hängt mit „Happy Eyeballs“ (RFC 6555 bzw. 8305) zusammen?

Siehe auch hier: https://www.mo4tech.com/curls-ipv6-and…n-policies.html insbesondere den Abschnitt über die zwei Queues für DNS-Anfragen über IPv4 bzw. IPv6.

Zitat von Real-DD-2

Einzig der SPF wird aktuell nicht erkannt.

Der SPF-Eintrag arbeitet anders als der _dmarc-Eintrag. Du musst den (zusätzlich) als TXT-Record für mail.mailrunner.de eintragen bzw. für die (Sub-)Domäne(n), von denen aus du E-Mails versenden möchtest.

Nachtrag: Hinweis auf Domänen ergänzt.

Ich arbeite lieber - wie tab - mit expliziten Einträgen und verwende Wildcard-Einträge gar nicht.

M. E. ist der MX-Record falsch, er darf gemäß RFC2181 nicht auf einen CNAME zeigen.

mail.mailrunner.de kann doch gar nicht aufgelöst werden, da hast du irgendwie lt. Bild 4 eine Loop konfiguriert.

Mach mal von extern einen nslookup mail.mailrunner.de, da kommt bei mir kein Ergebnis.

Port 25 für mailrunner.de wiederum wird mir als offen angezeigt.

Die einfachste Lösung wäre vermutlich der Wechsel auf einen alternativen E-Mail-Client wie beispielsweise Thunderbird.

Wenn das nicht gewünscht ist, könnte man untersuchen, ob es an fehlenden bzw. abgelaufenen Stammzertifikaten liegt. Diese ließen sich gegebenfalls manuell in der Schlüsselbundverwaltung von macOS importieren. Liegt es jedoch an fehlenden, moderneren Verschlüsselungsalgorithmen, kommt man hier nicht weiter.

Zu guter Letzt könnte man das Gerät mit Hilfe des OpenCore Legacy Patcher's auf ein neueres macOS hochziehen, siehe https://dortania.github.io/OpenCore-Legacy-Patcher/

Mit welchem OS setzt Ihr denn den systemd-resolved ein?

Ich habe zwei Rocky Linux 8 Server im Betrieb, einen aus 2024 ohne systemd-resolved und einen aus 2025 mit systemd-resolved.

Lt. Red Hat ist der Einsatz von systemd-resolved selbst bei RHEL 9 noch ein "Technology Preview" und nicht für den Produktiveinsatz empfohlen, siehe https://docs.redhat.com/en/documentati…ging-networking

Offenbar muss netcup am Image von Rocky Linux 8 etwas geändert haben, denn das originale Rocky Linux 8 Image wird auch heute noch ohne systemd-resolved ausgeliefert. Leider war meine Rückfrage diesbezüglich nicht wirklich erfolgreich.

Die Konfiguration beinhaltet u.a. folgende Parameter:

DNSSEC=false
DNSOverTLS=no

Die Konfiguration könnte sicherlich auch noch verbessert werden.

Das System läuft bislang anstandslos, lediglich bei Konfigurationsarbeiten ist uns aufgefallen, dass die beiden Server unterschiedlich konfiguriert sind.