Beim Anpassen von DKIM Records habe ich im Azure DNS Portal den neuen Punkt „DNSSEC“ entdeckt. Durch diese Grundvoraussetzung lässt sich jetzt auch DANE (Inbound) mit Exchange online implementieren – Yay!
Die wichtigste Voraussetzung zur Einrichtung von DANE für Exchange online ist ein DNS Provider / Domain Registrar, der auch DNSSEC unterstützt. In meinem Fall habe ich verschiedene Domains bei selfHOST registriert und die DNS Zonen bzw. die DNS Verwaltung liegt in Azure. selfHost selber signiert die DNS Zonen leider nicht. In der Konstellation mit externem DNS – wie in meinem Fall mit Azure DNS – kann der Support dort aber den benötigten DS Record veröffentlichen. Letztlich kann hier jeder Registrar (IONOS, United Domains, …) verwendet werden, der DNSSEC unterstützt. In meinem Fall war die Implementierung von DNSSEC denkbar einfach.
Vorbereitende Maßnahme „Aktivierung DNSSEC (Domain Name System Security Extensions)“:
- Im Azure Portal anmelden und in die DNS Zone der Wahl wechseln
- Bekannterweise führen viele Wege nach Rom
- Im linken Menü „DNS Management“ aufklappen und „DNSSEC“ wählen
- Auf der Seite „Übersicht“ im oberen Menü direkt den Punkt „DNSSEC“ wählen
- Die Checkbox „Enable DNSSEC“ aktivieren und den Hinweis absegnen
DNSSEC Details
Status: Signed but not delegated
To establish a DNSSEC chain of trust, you must add a DS record to the parent zone or registrar using the DNSSEC information obtained from your zone.
- Was mit den DNSSEC-Delegationsinformationen zu tun ist, hängt jetzt vom Registrar ab
- Bei selfHOST:
- Es kann sicherlich nicht schaden, vorher ein Ticket aufzumachen und auf das Vorhaben hinzuweisen. 🙂
- Für .cloud oder .it Domains: KeyTag, Algorithmus, Digest Typ und Digest an den Support übermitteln
- Für .de Domains: Schlüssel Flags, Schlüssel Protokoll, Algorithmus und den öffentlichen Schlüssel in BASE64
- IONOS: Setting Up and Managing DNNSEC – IONOS Help
- United Domains: DNS-Security (DNSSEC) | einfach erklärt | Help
- Bei selfHOST:
- Warten auf
s Christkinddie DNS Replikation – An dieser Stelle ist Zeit für Kaffee, Bier, Wasser, Tee oder auch nen Saft (wie Cola, Fanta, Mezzo Mix ;-))- An dieser Stelle Hut ab – à la bonne heure – für den selfHOST Support!
- Support Ticket ca. 10:10 Uhr erstellt
- Rückmeldung Support bzgl. Anforderung der Daten für den DS Record um 10:12 Uhr
- Daten wurden um 10:18 Uhr von mir geliefert
- Records um 10:23 Uhr vom selfHOST Support gesetzt
- An dieser Stelle Hut ab – à la bonne heure – für den selfHOST Support!
- Sobald der DS Record vorhanden ist wechselt der Status in den DNSSEC Details auf „Signed and delegation established“
DNSSEC Details
Status: Signed and delegation established
Bereiten wir uns auf DANE (DNS-based Authentication of Named Entities) für SMTP vor:
Im ersten Schritt kann es nicht schaden, die TTL (Time to Live) der involvierten DNS Records (MX Record, _mta-sts TXT Record) auf einen möglichst kleinen Wert (bspw. 60 Sekunden; Nicht kleiner 30 Sekunden) zu setzen. Kommt MTA-STS (Mail Transfer Agent-Strict Transport Security) zum Einsatz, sollte (besser muss!) der „mode“ der Policy in der „mta-sts.txt“ von „enforce“ auf „testing“ gesetzt werden. Je nach Länge des „max_age“ bietet es sich an diese ebenfalls auf eine kürzere Dauer (bspw. 1 Tag; 86400 Sekunden) zu konfigurieren sowie den entsprechenden _mta-sts TXT Record mit einer neuen Id (die aktuelle Zeit in UTC) sowie einer TTL von 60 Sekunden zu konfigurieren. Sollte MTA-STS nicht im Einsatz sein, könnte man im Anschluss der DANE Implementierung darüber nachdenken, ebenfalls auf MTA-STS zu setzen. Sollte es Konnektoren für die eigene Organisation oder Partner geben bzw. werden Mails von Appliances o.ä. direkt „jans-cloud.mail.protection.outlook.com“ (<domain>-<tld>.mail.protection.outlook.com) eingeliefert, so sollten diese umkonfiguriert werden auf „janscloud.onmicrosoft.com“ oder „janscloud.mail.protection.outlook.com“ bzw. möglichst nahtlos auf den neuen MX Endpoint „jans-cloud.y-v1.mx.microsoft“ geswitched werden.
- MTA-STS wird eingesetzt -> Wir warten geduldig auf die „max_age“ Zeitspanne!
- MTA-STS wird nicht eingesetzt -> Wir fahren direkt fort und implementieren MTA-STS im Nachgang (Enhancing mail flow with MTA-STS | Microsoft Learn). 😉
https://mta-sts.jans.cloud/.well-known/mta-sts.txt
# Vorher (max_age 7 Tage):
_mta-sta 3600 IN TXT "v=STSv1; id=20220708200000Z"
version: STSv1
mode: enforce
mx: jans-cloud.mail.protection.outlook.com
max_age: 604800
# Nachher (max_age 1 Tage):
_mta-sta 60 IN TXT "v=STSv1; id=20250327111111Z"
version: STSv1
mode: testing
mx: jans-cloud.mail.protection.outlook.com
max_age: 86400
DNS-based SMTP authentication of named entities (SMTP DANE) – Die wilde Fahrt beginnt:
- Es wird eine Verbindung mit der Exchange online Management PowerShell hergestellt
- „Enable-DnssecForVerifiedDomain“ wird ausgeführt
- Der Wert von „DnssecMxValue“ wird als weiterer MX im DNS mit niedriger Priorität (bspw. 20) sowie kurzer TTL (60 Sekunden) angelegt
- Nach einem weiteren Bier, Kaffee oder auch Tee sollte die SMTP Konnektivität gecheckt werden
- Sofern der Test für beide MX Records i.O. ist wird im DNS die Priorität gewechselt
- Der alte MX (jans-cloud.mail.protection.outlook.com) bekommt die niedrigere Priorität: 30
- Der neue MX (jans-cloud.y-v1.mx.microsoft) bekommt die höhere Priorität: 5
- Bemühen wir erneut den Remote Connectivity Analyzer mit dem Test „DNSSEC Prüfung“
- Microsoft-Remoteverbindungsuntersuchung: Testeingabe
- Nicht den Test „DANE Prüfung (einschließlich DNSSEC)“ nehmen!
- Der Test sollte an dieser Stelle positiv ausfallen. Klappt man das Ergebnis auf, sollte der MX mit der höheren Prio i.O. sein und der alte MX entsprechend nicht.
- Time to say goodbye: Der legacy MX (jans-cloud.mail.protection.outlook.com) wird gelöscht
- Wenn MTA-STS im Einsatz ist:
- mta-sts.txt bearbeiten
- den/die alten MX löschen
- den neuen MX einfügen
- _mta-sts TXT Record im DNS mit einer neuen Id (die aktuelle Zeit in UTC) pflegen
- mta-sts.txt bearbeiten
- SMTP DANE Inbound wird per „Enable-SmtpDaneInbound“ aktiviert
- Kommen wir zur nächsten Pause von ca. 10 bis 15 Minuten, damit die TLSA Records genug Zeit zum Propagieren haben
- Abschließend testen wir alles erneut. Dieses Mal nutzen wir den Test „DANE Prüfung (einschließlich DNSSEC)“
- Jetzt sollte der Mailflow getestet und eine Zeit lang beobachtet werden
- Wenn MTA-STS im Einsatz ist:
- Die Policy anpassen und den mode wieder auf „enforce“ konfigurieren
- Ebenfalls max_age wieder erhöhen
- Im _mta-sts DNS TXT Record eine neue Id in Form der UTC Zeit veröffentlichen
Hier der PowerShell Code Block mit den benötigten PowerShell Commands:
# Installation Exchange Online Management Modul
# Im Scope des Users; Benötigt keine administrativen Berechtigungen
# Install-Module -Name ExchangeonlineManagement `
# -Scope CurrentUser
#
# Für alle User; Benötigt administrative Berechtigungen
Install-Module -Name ExchangeonlineManagement
Connect-ExchangeOnline -UserPrincipalName post@jans.cloud
Enable-DnssecForVerifiedDomain -DomainName jans.cloud
# Output:
# DnssecMxValue Result ErrorData
# --------------------------------- ------ ---------
# jans-cloud.y-v1.mx.microsoft Success
# Es folgt Schritt 3 bis 8 bevor es hier mit Schritt 9 weiter geht
Enable-SmtpDaneInbound -DomainName jans.cloud
# Output:
# Result ErrorData
# ------ ---------
# Success
Ein erneuter Blick in die MTA-STS Konfiguration nach der Aktivierung von Inbound SMTP DANE in Exchange online:
# Vor Schritt 8:
_mta-sta 60 IN TXT "v=STSv1; id=20250327111111Z"
version: STSv1
mode: testing
mx: jans-cloud.mail.protection.outlook.com
max_age: 86400
# Nach Schritt 8:
_mta-sta 60 IN TXT "v=STSv1; id=20250327154500Z"
version: STSv1
mode: testing
mx: jans-cloud.y-v1.mx.microsoft
max_age: 86400
Der vorerst letzte Eingriff in die MTA-STS Policy / mta-sts.txt sowie den DNS TXT Record _mta-sts:
Zum Schluss kann die Policy wieder von „testing“ auf „enforce“ gesetzt werden und ebenfalls kann / könnte der Wert für „max_age“ wieder erhöht werden. Natürlich muss auch der TXT Record für _mta-sts im DNS wieder mit einer neuen Id versorgt werden. Zuerst im Codeblock die zuletzt aktive mta-sts.txt im Vergleich zur neuen, finalen. Danach folgt – wie gehabt – eine kurzer Bildband. 🙂
# Vorher; Nach der Implementierung von SMTP DANE:
_mta-sta 60 IN TXT "v=STSv1; id=20250327154500Z"
version: STSv1
mode: testing
mx: jans-cloud.y-v1.mx.microsoft
max_age: 86400
# Die (erstmal) finale Fassung:
_mta-sta 60 IN TXT "v=STSv1; id=20250328080000Z"
version: STSv1
mode: enforce
mx: jans-cloud.y-v1.mx.microsoft
max_age: 604800
Anpassen der Time to Live (TTL) der involvierten DNS Records auf den default Wert:
Nachdem wir jetzt ein paar Tage abgewartet haben und es keinerlei Problem gab, machen wir uns an die letzten Aufräumarbeiten im DNS und setzen die TTL der Einträge wieder auf den Standardwert von 3600 Sekunden (1 Stunde). Auf ins Azure DNS Portal und die TTL vom MX sowie _mta-sts TXT Record zurücksetzen.
Schreibe einen Kommentar