In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument wird die DANE-Implementierung für den ausgehenden E-Mail-Fluss der ESA beschrieben.
Allgemeine Kenntnisse über ESA-Konzepte und -Konfigurationen.
Anforderungen für die Implementierung von DANE:
DANE wurde in ESA 12 zur Validierung ausgehender E-Mails eingeführt.
DNS-basierte Authentifizierung benannter Entitäten (DANE).
Für die Implementierung von DANE ist eine DNS-Funktion zum Durchführen von dnssec/DANE-Abfragen erforderlich.
Zum Testen der ESA DNS DANE-Funktion kann ein einfacher Test über die ESA CLI-Anmeldung durchgeführt werden.
Der CLI-Befehl 'daneverify' führt die komplexen Abfragen aus, um zu überprüfen, ob eine Domäne die DANE-Verifizierung bestehen kann.
Derselbe Befehl kann mit einer zweifelsfrei funktionierenden Domäne verwendet werden, um die Fähigkeit der ESA zur Auflösung von dnssec-Abfragen zu bestätigen.
'ietf.org' ist eine weltweit bekannte Quelle. Durch die Ausführung des CLI-Befehls 'daneverify' wird überprüft, ob der DNS-Resolver DANE-fähig ist.
GÜLTIGER PASS: DANE-FÄHIGER DNS-SERVER "DANE SUCCESS" ERGEBNISSE FÜR ietf.org
> daneverify ietf.org
SECURE MX record(mail.ietf.org) found for ietf.org
SECURE A record (4.31.198.44) found for MX(mail.ietf.org) in ietf.org
Connecting to 4.31.198.44 on port 25.
Connected to 4.31.198.44 from interface 216.71.133.161.
SECURE TLSA record found for MX(mail.ietf.org) in ietf.org
Checking TLS connection.
TLS connection established: protocol TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384.
Certificate verification successful
TLS connection succeeded ietf.org.
DANE SUCCESS for ietf.org
DANE verification completed.
UNGÜLTIGER FEHLER: NICHT-DANE-FÄHIGE DNS-SERVER-"BOGUS"-ERGEBNISSE FÜR ietf.org
> daneverify ietf.org
BOGUS MX record found for ietf.org
DANE FAILED for ietf.org
DANE verification completed.
GÜLTIGER FEHLER: daneverify cisco.com > cisco hat DANE nicht implementiert. Dies ist das erwartete Ergebnis eines dnssec-fähigen Resolvers.
> daneverify cisco.com
INSECURE MX record(alln-mx-01.cisco.com) found for cisco.com
INSECURE MX record(alln-mx-01.cisco.com) found. The command will still proceed.
INSECURE A record (173.37.147.230) found for MX(alln-mx-01.cisco.com) in cisco.com
Trying next MX record in cisco.com
INSECURE MX record(rcdn-mx-01.cisco.com) found for cisco.com
INSECURE MX record(rcdn-mx-01.cisco.com) found. The command will still proceed.
INSECURE A record (72.163.7.166) found for MX(rcdn-mx-01.cisco.com) in cisco.com
Trying next MX record in cisco.com
INSECURE MX record(aer-mx-01.cisco.com) found for cisco.com
INSECURE MX record(aer-mx-01.cisco.com) found. The command will still proceed.
INSECURE A record (173.38.212.150) found for MX(aer-mx-01.cisco.com) in cisco.com
DANE FAILED for cisco.com
DANE verification completed.
Wenn die obigen Tests "GÜLTIG" funktionieren:
Absendergruppen-/Mail-Fluss-Richtlinien, für die die Aktion "RELAY" konfiguriert ist, führen eine DANE-Verifizierung durch.
Absendergruppen-/Mail-Fluss-Richtlinien, für die die Aktion "ACCEPT" konfiguriert wurde, führen KEINE DANE-Verifizierung durch.
Vorsicht: Wenn für die ESA in der Standardrichtlinie die Zielsteuerelemente "DANE" aktiviert sind, besteht das Risiko einer fehlerhaften Lieferung. Wenn eine interne Domäne wie die in der RAT aufgelisteten vorhanden ist, durchlaufen Sie sowohl die RELAY- als auch die ACCEPT-Mail Flow-Richtlinien, kombiniert mit dem Vorhandensein einer SMTP-Route für die Domäne.
DANE schlägt auf SMTP-Routen fehl, es sei denn, der "Ziel-Host" ist auf "USEDNS" konfiguriert.
DANE Opportunistic wird die Nachrichten, die sie enthalten, erst nach Ablauf des Bounce-Profil-Timers in der Zustellungswarteschlange zustellen.
Warum ist das so? Die DANE-Verifizierung wird übersprungen, da eine SMTP-Route eine Änderung des tatsächlichen Ziels darstellen würde und möglicherweise DNS nicht ordnungsgemäß verwendet.
Lösung: Erstellen von Zielsteuerungsprofilen zum expliziten Deaktivieren der DANE-Verifizierung für Domänen mit SMTP-Routen
Die folgenden Suchvorgänge werden während der DANE-Verifizierung durchgeführt.
Bei jeder Überprüfung wird der Inhalt eingespeist, um die nachfolgende Überprüfung durchzuführen.
Sicher:
Unsicher:
Falsch:
NXDOMAIN
Eine Kombination aus der oben genannten Datensatzprüfung und den Verifizierungsergebnissen bestimmt "DANE Success" | DANE Fail | DANE-Fallback zu TLS."
Beispiel: Wenn kein RRSIG für den MX-Datensatz von example.com gesendet wird, wird die übergeordnete Zone (.com) überprüft, um festzustellen, ob example.com einen DNSKEY-Datensatz hat. Dies bedeutet, dass example.com seine Datensätze signieren sollte. Diese Validierung setzt die Kette der Vertrauensstellung fort, die mit der Überprüfung des Schlüssels der Stammzone (.) abgeschlossen wird. Die Schlüssel der Stammzone stimmen mit den Erwartungen der ESA überein (hartcodierte Werte auf der ESA, die automatisch auf der Grundlage von RFC 5011 aktualisiert werden).
DANE MANDATORY
Hinweis: DANE OPPORTUNISTIC VERHÄLT SICH NICHT WIE TLS BEVORZUGT. Der ACTION-Teil der unten stehenden Tabelle Ergebnisse DANE FAIL, wird nicht für entweder obligatorisch oder opportunistisch. Die Nachrichten verbleiben in der Zustellungswarteschlange, bis der Zeitgeber abläuft. Anschließend wird die Zustellung beendet.
DANE OPPORTUNISTIC
In der folgenden Abbildung wird der Workflow veranschaulicht, wenn Sie DANE in einer Umgebung mit mehreren Appliances aktivieren.
Wenn die Umgebung über mehrere Schichten von ESA-Einheiten verfügt, eine für das Scannen und eine andere für die Zustellung von Nachrichten Stellen Sie sicher, dass DANE nur auf der Einheit konfiguriert wird, die direkt mit den externen Zielen verbunden ist.
Wenn auf einer ESA mehrere DNS-Resolver konfiguriert sind, von denen einige DNSSEC unterstützen, und einige DNSSEC nicht unterstützen, empfiehlt Cisco, die DNSSEC-fähigen Resolver mit einer höheren Priorität (niedrigerer numerischer Wert) zu konfigurieren, um Inkonsistenzen zu vermeiden.
Dadurch wird verhindert, dass der nicht DNSSEC-fähige Resolver die Zieldomäne, die DANE unterstützt, als 'Bogus' klassifiziert.
Wenn der DNS-Resolver nicht erreichbar ist, wird der DNS auf den sekundären DNS-Server zurückgeleitet. Wenn Sie DNSSEC nicht auf dem sekundären DNS-Server konfigurieren, werden die MX-Datensätze für DANE-fähige Zieldomänen als "Bogus" klassifiziert. Dies beeinflusst die Nachrichtenübermittlung unabhängig von den DANE-Einstellungen (opportunistisch oder obligatorisch). Cisco empfiehlt die Verwendung eines sekundären DNSSEC-fähigen Resolvers.
Zustellungsstatus
Überwachen Sie den WebUI-Bericht "Delivery Status" (Bereitstellungsstatus) auf unbeabsichtigte Aufbauvorgänge von Zieldomänen, die möglicherweise auf einen DANE-Fehler zurückzuführen sind.
Führen Sie diese Schritte aus, bevor Sie den Service aktivieren, und wiederholen Sie die Übung dann in regelmäßigen Abständen für mehrere Tage, um einen dauerhaften Erfolg zu gewährleisten.
ESA WebUI > Monitor > Delivery Status > überprüfen Sie die Spalte "Active Recipients" (Aktive Empfänger).
Mail-Protokolle
Standard-Mail-Protokolle auf Informationsebene für die Protokollebene.
Die E-Mail-Protokolle zeigen sehr subtile Indikatoren für erfolgreich von DANE ausgehandelte Nachrichten.
Die endgültige ausgehende TLS-Aushandlung umfasst eine leicht geänderte Ausgabe, die die Domäne am Ende des Protokolleintrags enthält.
Der Protokolleintrag enthält "TLS Success Protocol" gefolgt von "TLS version/cipher for domain.com".
Der Zauber liegt im "für":
myesa.local> grep "TLS success.*for" mail_logs
Tue Feb 5 13:20:03 2019 Info: DCID 2322371 TLS success protocol TLSv1.2 cipher DHE-RSA-AES256-GCM-SHA384 for karakun.com
Mail Logs debug
Benutzerdefinierte Mail-Protokolle auf Debug-Ebene zeigen vollständige DANE- und Dnssec-Suchvorgänge, erwartete Aushandlung, Teile der Prüfung, die erfolgreich/fehlgeschlagen ist, und einen Erfolgsindikator an.
Hinweis: Mail-Protokolle, die für die Debug Level-Protokollierung konfiguriert wurden, verbrauchen auf einer ESA je nach Systemlast und Konfiguration möglicherweise übermäßig viele Ressourcen.
Mail-Protokolle, die für die Debug Level-Protokollierung konfiguriert wurden, benötigen auf einer ESA je nach Systemlast und Konfiguration möglicherweise übermäßig viele Ressourcen.
E-Mail-Protokolle werden in der Regel NICHT über längere Zeiträume auf Debug-Ebene verwaltet.
Die Debug Level-Protokolle können innerhalb kurzer Zeit eine enorme Menge an Mail-Protokollen generieren.
Häufig wird ein zusätzliches Protokoll-Abonnement für mail_logs_d erstellt und die Protokollierung für DEBUG festgelegt.
Die Aktion verhindert die Beeinträchtigung der vorhandenen mail_logs und ermöglicht die Manipulation des Volumens der für das Abonnement verwalteten Logs.
Um die Menge der erstellten Protokolle zu kontrollieren, beschränken Sie die Anzahl der Dateien, die beibehalten werden sollen, auf eine kleinere Anzahl, z. B. 2-4 Dateien.
Wenn die Überwachung, der Testzeitraum oder die Fehlerbehebung abgeschlossen ist, deaktivieren Sie das Protokoll.
Die für den Debug-Level eingestellten Mail-Protokolle zeigen sehr detaillierte DANE-Ausgaben an:
Success sample daneverify
daneverify ietf.org
SECURE MX record(mail.ietf.org) found for ietf.org
SECURE A record (4.31.198.44) found for MX(mail.ietf.org) in ietf.org
Connecting to 4.31.198.44 on port 25.
Connected to 4.31.198.44 from interface 194.191.40.74.
SECURE TLSA record found for MX(mail.ietf.org) in ietf.org
Checking TLS connection.
TLS connection established: protocol TLSv1.2, cipher DHE-RSA-AES256-GCM-SHA384.
Certificate verification successful
TLS connection succeeded ietf.org.
DANE SUCCESS for ietf.org
DANE verification completed.
debug level mail logs during the above 'daneverify' exeuction.
Sample output from the execution of the daneverify ietf.org will populate the dns lookups within the mail logs
Mon Feb 4 20:08:47 2019 Debug: DNS query: Q('ietf.org', 'MX')
Mon Feb 4 20:08:47 2019 Debug: DNS query: QN('ietf.org', 'MX', 'recursive_nameserver0.parent')
Mon Feb 4 20:08:47 2019 Debug: DNS query: QIP ('ietf.org','MX','194.191.40.84',60)
Mon Feb 4 20:08:47 2019 Debug: DNS query: Q ('ietf.org', 'MX', '194.191.40.84')
Mon Feb 4 20:08:48 2019 Debug: DNSSEC Response data([(0, 'mail.ietf.org.')], secure, 0, 1800)
Mon Feb 4 20:08:48 2019 Debug: DNS encache (ietf.org, MX, [(8496573380345476L, 0, 'SECURE', (0, 'mail.ietf.org'))])
Mon Feb 4 20:08:48 2019 Debug: DNS query: Q('mail.ietf.org', 'A')
Mon Feb 4 20:08:48 2019 Debug: DNS query: QN('mail.ietf.org', 'A', 'recursive_nameserver0.parent')
Mon Feb 4 20:08:48 2019 Debug: DNS query: QIP ('mail.ietf.org','A','194.191.40.84',60)
Mon Feb 4 20:08:48 2019 Debug: DNS query: Q ('mail.ietf.org', 'A', '194.191.40.84')
Mon Feb 4 20:08:48 2019 Debug: DNSSEC Response data(['4.31.198.44'], secure, 0, 1800)
Mon Feb 4 20:08:48 2019 Debug: DNS encache (mail.ietf.org, A, [(8496573380345476L, 0, 'SECURE', '4.31.198.44')])
Mon Feb 4 20:08:48 2019 Debug: DNS query: Q('mail.ietf.org', 'AAAA')
Mon Feb 4 20:08:48 2019 Debug: DNS query: QN('mail.ietf.org', 'AAAA', 'recursive_nameserver0.parent')
Mon Feb 4 20:08:48 2019 Debug: DNS query: QIP ('mail.ietf.org','AAAA','194.191.40.84',60)
Mon Feb 4 20:08:48 2019 Debug: DNS query: Q ('mail.ietf.org', 'AAAA', '194.191.40.84')
Mon Feb 4 20:08:48 2019 Warning: Received an invalid DNSSEC Response: DNSSEC_Error('mail.ietf.org', 'AAAA', '194.191.40.84', 'DNSSEC Error for hostname mail.ietf.org (AAAA) while asking 194.191.40.84. Error was: Unsupported qtype') of qtype AAAA looking up mail.ietf.org
Mon Feb 4 20:08:48 2019 Debug: DNS query: Q('mail.ietf.org', 'CNAME')
Mon Feb 4 20:08:48 2019 Debug: DNS query: QN('mail.ietf.org', 'CNAME', 'recursive_nameserver0.parent')
Mon Feb 4 20:08:48 2019 Debug: DNS query: QIP ('mail.ietf.org','CNAME','194.191.40.83',60)
Mon Feb 4 20:08:48 2019 Debug: DNS query: Q ('mail.ietf.org', 'CNAME', '194.191.40.83')
Mon Feb 4 20:08:48 2019 Debug: DNSSEC Response data([], , 0, 1800)
Mon Feb 4 20:08:48 2019 Debug: Received NODATA for domain mail.ietf.org type CNAME
Mon Feb 4 20:08:48 2019 Debug: No CNAME record(NoError) found for domain(mail.ietf.org)
Mon Feb 4 20:08:49 2019 Debug: DNS query: Q('_25._tcp.mail.ietf.org', 'TLSA')
Mon Feb 4 20:08:49 2019 Debug: DNS query: QN('_25._tcp.mail.ietf.org', 'TLSA', 'recursive_nameserver0.parent')
Mon Feb 4 20:08:49 2019 Debug: DNS query: QIP ('_25._tcp.mail.ietf.org','TLSA','194.191.40.83',60)
Mon Feb 4 20:08:49 2019 Debug: DNS query: Q ('_25._tcp.mail.ietf.org', 'TLSA', '194.191.40.83')
Mon Feb 4 20:08:49 2019 Debug: DNSSEC Response data(['0301010c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6'], secure, 0, 1800)
Mon Feb 4 20:08:49 2019 Debug: DNS encache (_25._tcp.mail.ietf.org, TLSA, [(8496577312207991L, 0, 'SECURE', '0301010c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6')])
fail sample daneverify
[]> thinkbeyond.ch
INSECURE MX record(thinkbeyond-ch.mail.protection.outlook.com) found for thinkbeyond.ch
INSECURE MX record(thinkbeyond-ch.mail.protection.outlook.com) found. The command will still proceed.
INSECURE A record (104.47.9.36) found for MX(thinkbeyond-ch.mail.protection.outlook.com) in thinkbeyond.ch
Trying next A record (104.47.10.36) for MX(thinkbeyond-ch.mail.protection.outlook.com) in thinkbeyond.ch
INSECURE A record (104.47.10.36) found for MX(thinkbeyond-ch.mail.protection.outlook.com) in thinkbeyond.ch
DANE FAILED for thinkbeyond.ch
DANE verification completed.
mail_logs
Sample output from the execution of he danverify thinkbeyond.ch will populate the dns lookups within the mail logs
Mon Feb 4 20:15:52 2019 Debug: DNS query: Q('thinkbeyond.ch', 'MX')
Mon Feb 4 20:15:52 2019 Debug: DNS query: QN('thinkbeyond.ch', 'MX', 'recursive_nameserver0.parent')
Mon Feb 4 20:15:52 2019 Debug: DNS query: QIP ('thinkbeyond.ch','MX','194.191.40.84',60)
Mon Feb 4 20:15:52 2019 Debug: DNS query: Q ('thinkbeyond.ch', 'MX', '194.191.40.84')
Mon Feb 4 20:15:52 2019 Debug: DNSSEC Response data([(10, 'thinkbeyond-ch.mail.protection.outlook.com.')], insecure, 0, 3600)
Mon Feb 4 20:15:52 2019 Debug: DNS encache (thinkbeyond.ch, MX, [(8502120882844461L, 0, 'INSECURE', (10, 'thinkbeyond-ch.mail.protection.outlook.com'))])
Mon Feb 4 20:15:52 2019 Debug: DNS query: Q('thinkbeyond-ch.mail.protection.outlook.com', 'A')
Mon Feb 4 20:15:52 2019 Debug: DNS query: QN('thinkbeyond-ch.mail.protection.outlook.com', 'A', 'recursive_nameserver0.parent')
Mon Feb 4 20:15:52 2019 Debug: DNS query: QIP ('thinkbeyond-ch.mail.protection.outlook.com','A','194.191.40.83',60)
Mon Feb 4 20:15:52 2019 Debug: DNS query: Q ('thinkbeyond-ch.mail.protection.outlook.com', 'A', '194.191.40.83')
Mon Feb 4 20:15:52 2019 Debug: DNSSEC Response data(['104.47.9.36', '104.47.10.36'], insecure, 0, 10)
Mon Feb 4 20:15:52 2019 Debug: DNS encache (thinkbeyond-ch.mail.protection.outlook.com, A, [(8497631700844461L, 0, 'INSECURE', '104.47.9.36'), (8497631700844461L, 0, 'INSECURE', '104.47.10.36')])
Mon Feb 4 20:15:52 2019 Debug: DNS query: Q('thinkbeyond-ch.mail.protection.outlook.com', 'AAAA')
Mon Feb 4 20:15:52 2019 Debug: DNS query: QN('thinkbeyond-ch.mail.protection.outlook.com', 'AAAA', 'recursive_nameserver0.parent')
Mon Feb 4 20:15:52 2019 Debug: DNS query: QIP ('thinkbeyond-ch.mail.protection.outlook.com','AAAA','194.191.40.84',60)
Mon Feb 4 20:15:52 2019 Debug: DNS query: Q ('thinkbeyond-ch.mail.protection.outlook.com', 'AAAA', '194.191.40.84')
Mon Feb 4 20:15:52 2019 Debug: DNSSEC Response data([], , 0, 32768)
Mon Feb 4 20:15:52 2019 Debug: Received NODATA for domain thinkbeyond-ch.mail.protection.outlook.com type AAAA
Mon Feb 4 20:15:52 2019 Debug: DNS query: Q('thinkbeyond-ch.mail.protection.outlook.com', 'CNAME')
Mon Feb 4 20:15:52 2019 Debug: DNS query: QN('thinkbeyond-ch.mail.protection.outlook.com', 'CNAME', 'recursive_nameserver0.parent')
Mon Feb 4 20:15:52 2019 Debug: DNS query: QIP ('thinkbeyond-ch.mail.protection.outlook.com','CNAME','194.191.40.83',60)
Mon Feb 4 20:15:52 2019 Debug: DNS query: Q ('thinkbeyond-ch.mail.protection.outlook.com', 'CNAME', '194.191.40.83')
Mon Feb 4 20:15:53 2019 Warning: Received an invalid DNS Response: SERVER FAILED to IP 194.191.40.83 looking up thinkbeyond-ch.mail.protection.outlook.com
Mon Feb 4 20:15:53 2019 Debug: DNS query: QIP ('thinkbeyond-ch.mail.protection.outlook.com','CNAME','194.191.40.84',60)
Mon Feb 4 20:15:53 2019 Debug: DNS query: Q ('thinkbeyond-ch.mail.protection.outlook.com', 'CNAME', '194.191.40.84')
Mon Feb 4 20:15:54 2019 Warning: Received an invalid DNS Response: SERVER FAILED to IP 194.191.40.84 looking up thinkbeyond-ch.mail.protection.outlook.com
Mon Feb 4 20:15:54 2019 Debug: No CNAME record() found for domain(thinkbeyond-ch.mail.protection.outlook.com)
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
26-Aug-2019 |
Erstveröffentlichung |