DANE für E-Mail Security Appliance

Einleitung

In diesem Dokument wird die DANE-Implementierung für den ausgehenden E-Mail-Fluss der ESA beschrieben.

Voraussetzungen

Allgemeine Kenntnisse über ESA-Konzepte und -Konfigurationen.

Anforderungen für die Implementierung von DANE:

• DNSSEC-fähiger DNS-Resolver
• ESA mit AsyncOS 12.0 oder neuer

Hintergrundinformationen

DANE wurde in ESA 12 zur Validierung ausgehender E-Mails eingeführt.

DNS-basierte Authentifizierung benannter Entitäten (DANE).

• DANE ist ein Internet-Sicherheitsprotokoll, mit dem digitale X.509-Zertifikate mit DNSSEC an Domänennamen gebunden werden können. (RFC 6698)
• DNSSEC ist eine Sammlung von IETF-Spezifikationen zum Sichern von DNS-Datensätzen mithilfe von Kryptografie mit öffentlichem Schlüssel. (Sehr elementare Erklärung. RFC 4033, RFC 4034 und RFC 4035)

Überlegungen zur Implementierung

Vergewissern Sie sich, dass die ESA einen dnssec-fähigen DNS-Resolver verwendet.

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:

• Ein vorsichtiger Ansatz wäre es, jede Domäne zu testen, bevor ein Profil für die Domäne hinzugefügt wird.
• Ein aggressiverer Ansatz wäre die Konfiguration von DANE im Standardzielsteuerungsprofil, um festzustellen, wer erfolgreich ist und wer ausfällt.

Mail Direction bestimmt, ob DANE dies verifiziert.

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.

SMTP-Routen

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

DANE Opportunistic oder DANE Obligatorisch

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.

• MX Record lookup verifiziert, ob >>> Sicher, Unsicher, Bogus
• Eine Datensatzsuche verifiziert, ob >>> Secure Insecure > Bogus
• TLSA-Datensatzsuche überprüft, ob >>> Sicher, Unsicher, Bogus, NXDOMAIN
• Zertifikatsprüfung >> Erfolg, Fehler

Sicher:

• DNS hat das Vorhandensein eines sicheren Eintrags überprüft, der einen RRSIG-validierten signierten RRSIG-DS und DNSKEY in der gesamten Vertrauenskette enthält.

Unsicher:

• DNS bestimmt, dass in der Domäne keine dnssec-aktivierten Datensätze vorhanden sind. 

Falsch:

• Unvollständig, die aktuellen dnssec-Einträge können jedoch nicht überprüft werden.
• Ungültige Datensätze aufgrund eines abgelaufenen Schlüssels.
• Datensatz oder Schlüssel in Vertrauenskette fehlt.

NXDOMAIN

• Kein Eintrag im DNS gefunden.

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

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

DANE OPPORTUNISTIC

DANE in Umgebungen mit mehreren Appliances aktivieren

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.

Multi-ESA-Design. DANE auf der ESA für die Zustellung konfiguriert

Verwalten mehrerer DNS-Resolver

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.

Verwalten des sekundären DNS-Servers

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.

Konfiguration

Konfigurieren Sie DANE für den ausgehenden E-Mail-Fluss.

1. WebUI Navigieren zu > Mail-Policys > Zielsteuerelemente > Ziel hinzufügen
2. Füllen Sie den oberen Teil des Profils entsprechend Ihrer Präferenz aus.
3. TLS-Support: muss auf "TLS Preferred" (TLS bevorzugt) gesetzt werden. | Bevorzugt - Verifizieren | Erforderlich | Erforderlich - Verifizieren| Erforderlich - Gehostete Domäne verifizieren."
4. Sobald der TLS-Support aktiviert wurde, wird das Dropdown-Menü DANE Support: (DANE-Support:) aktiviert.
5. DANE-Unterstützung: Optionen: "Keine | Opportunistisch | Obligatorisch
6. Sobald die DANE-Support-Option abgeschlossen ist, senden und bestätigen Sie die Änderungen.

Zielsteuerungsprofil - DANE-Überprüfung

DANE-Erfolg überprüfen

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)

Zugehörige Informationen

• ESA-Bedienungsanleitungen
• ESA-Versionshinweise
• ESA-CLI-Referenzhandbücher