Dieser Beitrag ist für Administratoren und Entscheider gedacht, die ebenfalls vor der Herausforderung stehen bzw. darüber nachdenken für Ihre Domain DNSSEC und DANE umzusetzen und erstmal den Wald vor lauter Bäumen nicht sehen!
In meinem Fall fing die Geschichte mit einer Rückfrage meines Chefs an (Auszug aus der Orientierungshilfe der Datenschutzaufsichtsbehörden):
[...]
Die Bezeichnung der zum Empfang autorisierten Mailserver und ihre IP-Adressen wurden auf Empfängerseite per DNSSEC signiert. Die Signaturen der DNS Einträge werden auf Senderseite überprüft. Alternativ kann die Bezeichnung der zum Empfang autorisierten Mailserver auch durch Kommunikation mit dem Empfänger verifiziert werden.
[...]
Ich habe interpretiert wir müssen DNSSEC und DANE anbieten, im Nachgang wohl eher unser E-Mail-Gateway soll dies prüfen können. Aber eine Domain mehr die es anbietet macht die Welt sicher zu einem sichereren Platz
DNSSEC: technischen Hintergründe und Auswirkung im Betrieb
Bei DNSSEC geht es stark vereinfacht darum DNS-Antworten z.B. "Was ist der MX von der Zone nospamproxy.com" eine Authentizität zu verleihen. Also ein Schutz gegen Manipulation durch kryptografische Berechnung und Abgleich des Ergebnisses, anstatt blinden Vertrauen.
Nicht zu verwechseln mit der Transportverschlüsselung wie TLS – hier geht es um eine geheime Übermittlung von Informationen.
In der Praxis klappt dies durch die Gruppierung von Einträgen anhand des Typs und der Zone z.B. alle MX-Einträge, alle A-Eintrage in der Zone nospamproxy.com zu RRSets (Ressource Record Sets)
Diese RRSets werden dann gehashed und dieser Hash mit einem Private-Public Keypair (ZSK = Zone Signing Key) verschlüsselt.
In der Zone stehen dann neben den regulären Daten die folgenden:
RRSig (Ressource Record Signatur)
DNSKEY (öffentliches Schlüsselmaterial des ZSK)
Die „Chain of Trust“ oder Bürgschaft wird via dem KSK (Key Signing Key) erreicht, dieser signiert den DNSKEY-Eintrag. Der Hash des öffentlichen KSK wird dann an die Elternzone übergeben, welcher diesen bei sich als DS-Record in unserem Beispiel bei der .com-Zone veröffentlicht.
Der Betreiber der .com-Zone wiederrum wird von der root-Zone signiert (gleiches Verfahren) und dieser wird per Definition vertraut!
Somit entsteht eine Kette des Vertrauens von der Root-Zone runter bis zu nospamproxy.com.
Eine nennenswerte Besonderheit ist noch der NSEC-Eintrag. Mit dem Hintergrund das DNSSEC immer eine signierte Antwort zurückgeben muss und NXDOMAIN kryptografisch nicht nachweisbar ist (Nichts hashen klappt nicht, Stichwort: DKIM auf leeren Body), wird ein NSEC oder NSEC3 Eintrag zurück geben.
Dieser beinhaltet als Antwort die Zone vor und nach der angefragten Zone.
Bespiel:
Frage: Gibt es billing.nospamproxy.com
Antwort: Nein, den es existiert answer.nospamrpoy.com vor und consultung.nospamproxy.com danach der angefragten Zone!
Dies kann zur Iteration der Zonen und dem Aufdecken „versteckter“ DNS-Zonen führen, als Abhilfe wurde NSEC3 implementiert, was das Problem mindert, aber nicht löst – dies ist jedoch ein anderes Thema und soll nicht Bestandteil dieses Posts sein!
Bei der DNS-Abfragen gegen einen DNSSEC aktivierten DNS-Server kann der Client welcher den Standard ebenfalls unterstützt nun die DNS-Antwort gegen prüfen und mit den Informationen wie dem RRSig, dem Fingerabdruck des öffentlichen Schlüssels (unter Absicherung des KSK) nun selbst errechnen ob die RRSig integer ist.
In der Praxis bleibt je nach DNS-Provider (in meinem Umsetzung Azure Public DNS) hiervon vieles unbemerkt, was anfangs kompliziert klingt
.
Die Aktivierung findet via einer Checkbox statt und der DS-Eintrag muss an den Registrar zu Eintragung in der Elternzone gemeldet werden. Die Rotation des ZSK findet automatisch statt, der KSK wird per Definition nicht rotiert -> Meldung an Registrar notwendig.
Wichtig in der effektiven Implementierung als Client ist die Position des DNS-Resolvers ist: Desto näher an der Applikation z.B. der NoSpamProxy-App selbst, desto sicherer die Antwort:
DANE: technischen Hintergründe und Auswirkung im Betrieb
Kommen wir nun zu DANE, welches DNSSEC voraussetzt. Ziel von DANE ist es, dem sendenden E-Mailserver klar mitzuteilen, mit welchem empfangenden Hostname dieser zu kommunizieren hat.
Hierzu werden Informationen wie der Port, das Protokoll, der Hostname, eine Reihe an Anweisungen zur Berechnung des Hashes sowie der Hash des öffentlichen Zertifikates in einem TLSA-Eintrag in der Zone, gesichert gegen Manipulation per DNSSEC, auf Anfrage mitgeteilt.
Ein exakter Bauplan mit allen Daten, der Weg zur Lösung und die Lösung selbst.
Schauen wir uns einmal den aktuellen, relevanten TLSA-Eintrag vom BSI, NoSpamProxy und Web.de an (die Hashes sind abgekürzt):
So sieht man das auf Port: 25, Protokoll: TCP der Hostname: netatwork-de.mail.cloud.nospamproxy.com für den E-Mailempfang zu erreichen ist.
Der Hash (am Ende) kann wie folgt berechnet und verglichen werden: Beachte nur das Zertifikat vom TLS-Verbindngsaufbau, konkret "End-Entity" (intermediate/ root sind egal), bilde einen Hash des öffentlichen Schlüssels des Zertifikates und hashe diesen Wert nach SHA-256. Der Hash den du erhälst muss dem aus dem TLSA-Record entsprechen:
Mit Blick auf den Betrieb ist hierbei wichtig: Mit dem Wechsel des TLS-Zertifikates muss auch der TLSA-Eintrag angepasst werden.
Zum Glück des Admins kann es mehrere TLSA-Einträge gleichzeitig geben, somit kann der neue Eintrag schon verteilt werden, während das aktive Zertifikat demnächst ausläuft und rechtzeitig zuvor gewechselt wird.
Teilt gerne eure Erfahrungen/ Stände der Umsetzung (Kein Planung zur Umsetzung weil..., in Planung,Status: ..., Umgesetzt seit 20XX und Erfahrungen) zu DNSSEC und DANE, das dürfte für die anderen Forenmitglieder sicherlich auch interessant sein
LG
Fabian
In meinem Fall fing die Geschichte mit einer Rückfrage meines Chefs an (Auszug aus der Orientierungshilfe der Datenschutzaufsichtsbehörden):
[...]
Die Bezeichnung der zum Empfang autorisierten Mailserver und ihre IP-Adressen wurden auf Empfängerseite per DNSSEC signiert. Die Signaturen der DNS Einträge werden auf Senderseite überprüft. Alternativ kann die Bezeichnung der zum Empfang autorisierten Mailserver auch durch Kommunikation mit dem Empfänger verifiziert werden.
[...]
Ich habe interpretiert wir müssen DNSSEC und DANE anbieten, im Nachgang wohl eher unser E-Mail-Gateway soll dies prüfen können. Aber eine Domain mehr die es anbietet macht die Welt sicher zu einem sichereren Platz
DNSSEC: technischen Hintergründe und Auswirkung im Betrieb
Bei DNSSEC geht es stark vereinfacht darum DNS-Antworten z.B. "Was ist der MX von der Zone nospamproxy.com" eine Authentizität zu verleihen. Also ein Schutz gegen Manipulation durch kryptografische Berechnung und Abgleich des Ergebnisses, anstatt blinden Vertrauen.
Nicht zu verwechseln mit der Transportverschlüsselung wie TLS – hier geht es um eine geheime Übermittlung von Informationen.
In der Praxis klappt dies durch die Gruppierung von Einträgen anhand des Typs und der Zone z.B. alle MX-Einträge, alle A-Eintrage in der Zone nospamproxy.com zu RRSets (Ressource Record Sets)
Diese RRSets werden dann gehashed und dieser Hash mit einem Private-Public Keypair (ZSK = Zone Signing Key) verschlüsselt.
In der Zone stehen dann neben den regulären Daten die folgenden:
RRSig (Ressource Record Signatur)
DNSKEY (öffentliches Schlüsselmaterial des ZSK)
Die „Chain of Trust“ oder Bürgschaft wird via dem KSK (Key Signing Key) erreicht, dieser signiert den DNSKEY-Eintrag. Der Hash des öffentlichen KSK wird dann an die Elternzone übergeben, welcher diesen bei sich als DS-Record in unserem Beispiel bei der .com-Zone veröffentlicht.
Der Betreiber der .com-Zone wiederrum wird von der root-Zone signiert (gleiches Verfahren) und dieser wird per Definition vertraut!
Somit entsteht eine Kette des Vertrauens von der Root-Zone runter bis zu nospamproxy.com.
Eine nennenswerte Besonderheit ist noch der NSEC-Eintrag. Mit dem Hintergrund das DNSSEC immer eine signierte Antwort zurückgeben muss und NXDOMAIN kryptografisch nicht nachweisbar ist (Nichts hashen klappt nicht, Stichwort: DKIM auf leeren Body), wird ein NSEC oder NSEC3 Eintrag zurück geben.
Dieser beinhaltet als Antwort die Zone vor und nach der angefragten Zone.
Bespiel:
Frage: Gibt es billing.nospamproxy.com
Antwort: Nein, den es existiert answer.nospamrpoy.com vor und consultung.nospamproxy.com danach der angefragten Zone!
Dies kann zur Iteration der Zonen und dem Aufdecken „versteckter“ DNS-Zonen führen, als Abhilfe wurde NSEC3 implementiert, was das Problem mindert, aber nicht löst – dies ist jedoch ein anderes Thema und soll nicht Bestandteil dieses Posts sein!
Bei der DNS-Abfragen gegen einen DNSSEC aktivierten DNS-Server kann der Client welcher den Standard ebenfalls unterstützt nun die DNS-Antwort gegen prüfen und mit den Informationen wie dem RRSig, dem Fingerabdruck des öffentlichen Schlüssels (unter Absicherung des KSK) nun selbst errechnen ob die RRSig integer ist.
In der Praxis bleibt je nach DNS-Provider (in meinem Umsetzung Azure Public DNS) hiervon vieles unbemerkt, was anfangs kompliziert klingt
.Die Aktivierung findet via einer Checkbox statt und der DS-Eintrag muss an den Registrar zu Eintragung in der Elternzone gemeldet werden. Die Rotation des ZSK findet automatisch statt, der KSK wird per Definition nicht rotiert -> Meldung an Registrar notwendig.
Wichtig in der effektiven Implementierung als Client ist die Position des DNS-Resolvers ist: Desto näher an der Applikation z.B. der NoSpamProxy-App selbst, desto sicherer die Antwort:
DANE: technischen Hintergründe und Auswirkung im Betrieb
Kommen wir nun zu DANE, welches DNSSEC voraussetzt. Ziel von DANE ist es, dem sendenden E-Mailserver klar mitzuteilen, mit welchem empfangenden Hostname dieser zu kommunizieren hat.
Hierzu werden Informationen wie der Port, das Protokoll, der Hostname, eine Reihe an Anweisungen zur Berechnung des Hashes sowie der Hash des öffentlichen Zertifikates in einem TLSA-Eintrag in der Zone, gesichert gegen Manipulation per DNSSEC, auf Anfrage mitgeteilt.
Ein exakter Bauplan mit allen Daten, der Weg zur Lösung und die Lösung selbst.
| Feld | Hinweis | Wert | Beschriebung |
| CUF | PKIX | 0 | Vertraue der öffentliche CA + DANE als Zusatzprüfung |
| CUF | PKIX-EE | 1 | Zertifikat (Prüfung) + Quelle muss öffentliche CA sein |
| CUF | DANE-TA2 | 2 | Siehe PKIX-TA – eigene PKI möglich. |
| CUF | DANE-EE | 3 | Exaktes Serverzertifikat, keine Vertrauenskette |
| SF | Full Certificate | 0 | Das vollständige Zertifikat wird genutzt. |
| SF | SubjectPublicKeyInfo | 1 | Nur der öffentliche Schlüssel wird genutzt. |
| MTF | Full | 0 | Vollständiges Zertifikat, kein Hash |
| MTF | SHA-256 | 1 | SHA-256 Hash-Wert |
| MTF | SHA-512 | 2 | SHA-512 Hash-Wert |
Schauen wir uns einmal den aktuellen, relevanten TLSA-Eintrag vom BSI, NoSpamProxy und Web.de an (die Hashes sind abgekürzt):
So sieht man das auf Port: 25, Protokoll: TCP der Hostname: netatwork-de.mail.cloud.nospamproxy.com für den E-Mailempfang zu erreichen ist.
Der Hash (am Ende) kann wie folgt berechnet und verglichen werden: Beachte nur das Zertifikat vom TLS-Verbindngsaufbau, konkret "End-Entity" (intermediate/ root sind egal), bilde einen Hash des öffentlichen Schlüssels des Zertifikates und hashe diesen Wert nach SHA-256. Der Hash den du erhälst muss dem aus dem TLSA-Record entsprechen:
Mit Blick auf den Betrieb ist hierbei wichtig: Mit dem Wechsel des TLS-Zertifikates muss auch der TLSA-Eintrag angepasst werden.
Zum Glück des Admins kann es mehrere TLSA-Einträge gleichzeitig geben, somit kann der neue Eintrag schon verteilt werden, während das aktive Zertifikat demnächst ausläuft und rechtzeitig zuvor gewechselt wird.
Teilt gerne eure Erfahrungen/ Stände der Umsetzung (Kein Planung zur Umsetzung weil..., in Planung,Status: ..., Umgesetzt seit 20XX und Erfahrungen) zu DNSSEC und DANE, das dürfte für die anderen Forenmitglieder sicherlich auch interessant sein
LG
Fabian
Zuletzt bearbeitet:
