Hornetsecurity Störung 7. Jun 2024

Am 7. Jun war einer meiner Kunden von einem Ausfall bei Hornet Security betroffen. Ich möchte auf dieser Seite nicht nur das Fehlerbild und mögliche Ursachen beschreiben sondern generell den Umgang mit solchen Problemen eines vorgelagerten Spamfilters beleuchten. Es könnt ja auch mal NoSpamProxy betreffen und als Betreiber einer Domain sollten Sie immer einen Plan-B haben. Und was liegt näher als eine realen Störung zu analysieren und daraus Verbesserungen auch für den eigenen Betrieb herzuleiten. Vielleicht lernen meine Leser auch noch aus der Analyse ein Vorgehen für ihr nächstes Problem.

Es geht hier nicht darum, einen Marktbegleiter von NoSpamProxy schlecht aussehen zu lassen. Menschen machen Fehler und wer nichts macht, verändert auch Nichts zum Guten. Aber aus vergangenen Fehlern können wir alle lernen, damit sie diese nicht wiederholen. Dies ist nicht die erste Seite zu einem Ausfall. Siehe auch Confluence CVE-2022-26134

Fehlerbild

Angefangen hat es mit dem Anruf eines Kunden, dass er seit ca. 9:20 Uhr keine Mails mehr über Hornet Security senden kann und auch keine Mails mehr bekommt. er bekam folgende Fehlermeldung beim Versand von Exchange Online:

Remote server returned '550 5.4.310 DNS domain relay-cluster-eu01.Hornetsecurity.com does not exist 
[Message=InfoDomainNonexistent] [LastAttemptedServerName=relay-cluster-eu01.Hornetsecurity.com] 
[AM7EUR03FT024.eop-EUR03.prod.protection.outlook.com 2024-06-07T07:20:36.724Z 08DC866FB337FE32]'

Beim Kunden ist in Exchange Online ein "Outbound-Connector to Hornet" angelegt, bei dem alles Mails an die Domain "*" über den Server "relay-cluster-eu01.Hornetsecurity.com" geroutet werden und den kann Exchange Online nicht auflösen.

Im Messagetrackinglog von Exchange ist zu sehen, dass er den Namen nicht auflösen kann.

Reason: [{LED=550 5.4.310 DNS domain relay-cluster-eu01.Hornetsecurity.com does not exist 
[Message=InfoDomainNonexistent] [LastAttemptedServerName=relay-cluster-eu01.Hornetsecurity.com] 
[VE1EUR01FT030.eop-EUR01.prod.protection.outlook.com 2024-06-07T11:39:53.830Z 08DC868D339A869C]};
{MSG=InfoDomainNonexistent};{FQDN=relay-clust. OutboundProxyTargetHostName: relay-cluster-eu01.Hornetsecurity.com

Ich finde es interessant, dass Exchange Online eine Mail an einen Smarthost, der nicht auflösbar ist, direkt mit einem 550 Error verwirft.

Verlorene Mails

Ich hätte mir eigentlich gewünscht, dass Exchange in so einem Fall die Mail erst einmal zurückstellt und später weiter versucht. Das gleiche vorgehen gilt auch für Mails, die über einen MX-Record zugestellt werden. Wenn ein MX-Record auf Server verweist, die alle nicht auflösbar sind, dann bekommt die Domain den Status "NXDOMAIN" und Mails werden verworfen

Das individuelle Verhalten ist natürlich vom jeweiligen Mailserver abhängig, wie dieser Sonderfall implementiert wurde. Aber es ist sehr wahrscheinlich, dass Mails an Kunden von Hornet direkt vom Mailserver des Absenders schon einen NDR bekommen haben, da die Domain "Hornetsecurity.com" nicht auflösbar ist. Dass dem so war, zeigen die weiteren Analyseschritte:

Diese Verhalten ist natürlich besonders nachteilig für "automatisierte Mails", die nicht durch Menschen gesendet oder verarbeitet werden, z.B. Bestellungen, Rechnungsempfang, M2M-Kommunikation etc. SMTP ist keine "zuverlässige" Übertragung. Wer Transaktionen per Mail übermittelt, muss sich um NDRs kümmern und idealerweise mit Transaktionsnummern auch Verluste erkennen und "heilen" können. Kritisch ist dies natürlich, wenn z.B. per SMTP auch Compliance/Archiv-Mails an ein Archivsystem übertragen werden und diese in der Zeit auch verworfen wurden.

Das bestätigt wieder meine Forderung, dass die Nutzung einer "Noreply"-Adresse eigentlich ein Armutszeugnis für den Absender ist.

Achtung: Dies gilt auch für SPF-Einträge. Wenn Sie in ihrer Domain z.B. einen "include:<3rd.party.domain>" haben und die Domain nicht auflösbar ist, dann gilt der ganze SPF-Eintrag als "nicht gesetzt". Damit werden Mails von ihrem Server vielleicht nicht zugestellt, weil die Gegenseite eine SPF-Prüfung vorschreibt oder zumindest Domains ohne einen SPF-Eintrag schlechter bewertet.

Zur Klarstellung: Hornetsecurity hat vermutlich keine Mails "verloren" oder gelöscht. Mail wurden von den Mailservern gelöscht, die bei einer Auflösung auf "NXDOMAIN" diese nicht zurückstellen und erneut versuchen. Das betraf dann alle Kunden, die ihre Mails ins Internet über Hornetsecurity als Smarthost senden oder bei deren MX-Record auf die Server von Hornetsecurity verweisen. "Menschen" könnten das lesen, verstehen und die Mail erneut senden. Kritisch sind automatische Prozesse.

DNS-Anfragen

Also starten wir ein paar DNS-Anfragen. Ich weiß zwar nicht, welche Server Exchange Online fragt, aber die bekannten Server kennen die Adresse nicht mehr.

Gibt es denn die Zone noch?

Also gibt es die Domain noch und wird von "domaincontrol.com" gehostet. Dann fragen wir doch diesen Server einmal.

Das dürfte dann der Root-Cause sein. Die Root-Server leiten meine Anfragen noch zu domaincontrol.com, die aber keine Zone mehr für Hornetsecurity.com haben. Damit ist natürlich auch erklärbar, dass nicht nur relay-cluster-eu01.Hornetsecurity.com unauffindbar ist, sondern auch noch alle anderen Adressen, die für eine Kundenkommunikation interessant sind, z.B.

  • https://www.Hornetsecurity.com
  • https://status.Hornetsecurity.com

Auch die anderen "öffentlichen DNS-Server" finden die Adressen nicht mehr:

PS C:\> nslookup -q=A www.Hornetsecurity.com 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Nicht autorisierende Antwort:
Name:    www.Hornetsecurity.com
Address:  194.6.209.34

PS C:\> nslookup -q=A www.Hornetsecurity.com 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1

*** www.Hornetsecurity.com wurde von one.one.one.one nicht gefunden: Non-existent domain.

Eine schnelle Lösung gibt es dazu natürlich erst einmal nicht. Domaincontrol.com ist eigentlich ein "großer DNS-Provider" und wenn Hornetsecurity seine Rechnungen bezahlt hat, sollten diese nicht ihren Dienst abschalten.

Umzug der Zone

Dann habe ich mal die Root-Server für die COM-Domain gesucht. Über eine Anfrage an "a.root-server.com" bekomme ich z.B.

PS C:\> nslookup -q=NS Hornetsecurity.com. a.root-servers.net
Server:  UnKnown
Address:  198.41.0.4

com     nameserver = l.gtld-servers.net
com     nameserver = j.gtld-servers.net
com     nameserver = h.gtld-servers.net
...

Also habe ich bei "l.gtld-servers.net internet address = 192.41.162.30" gefragt, war er von Hornetsecurity.com kennt.

PS C:\> nslookup Hornetsecurity.com l.gtld-servers.net
Server:  UnKnown
Address:  192.41.162.30

Name:    Hornetsecurity.com
Served by:
- godzilla-haj2.antispameurope.de
          Hornetsecurity.com
- pdns02.domaincontrol.com
          173.201.78.50
          2603:5:22e0::32
          Hornetsecurity.com

Hier taucht das erste mal ein neuer DNS-Server "godzilla-haj2.antispameurope.de" auf. Ob dies ein dauerhafter Name ist, lasse ich mal dahingestellt. Wenn ich aber den Server frage, dann bekomme ich sehr wohl gültige Antworten:

Es hat den Anschein, dass Hornetsecurity den DNS-Provider wechselt und die Zone auf eigene Server umzieht. Dazu sind natürlich zwei Dinge wichtig:

  • Übertragen der Zone
    Die neuen Server benötigen eine aktuelle Kopie der DNS-Zone. Wer Zugriff auf den BIND hat, kann dies über eine Kopie der Zonendatei oder über eine DNS-Replikation (Primary/Secondary) erreichen. Welchen Weg domaincontrol.com zum Export anbietet, weiß ich nicht. Hier dürfte aber kein Fehler passiert sein.
  • Umhängen der Zone
    Der kniffligere Teil ist aber die Anpassung in der "com."-DNS-Zone bei "gtld-servers.net". Dort ist der Verweis für die Zone "Hornetsecurity.com" auf die Nameserver von domaincontrol.com. Diese müssen auf die neuen DNS-Server für die Zone umgestellt werden.

Die Problematik dabei ist, dass DNS mit Caching arbeitet und jeder Eintrag einen TTL hat. Wird der Eintrag in gtld-servers.net geändert, dann wird dies nicht sofort aktiv. Woran es nun im Details lagt, habe ich nicht weiter recherchiert.

Workaround Ausgehend

Das Problem beruhte also auf einer Fehlkonfiguration der Namensauflösung. Wenn aber ein System die richtigen IP-Adressen kennen würde, dann kann ich die Namensauslösung auch umgehen. Da nicht alle DNS-Server im Internet zur gleichen Zeit ihren Cache leeren und die IP-Adressen hinter "relay-cluster-eu01.Hornetsecurity.com" zudem in der Kundenfirewall explizit hinterlegt waren, konnte ich z.B. in Exchange Online die IP-Adresse statt des DNS-Namens eintragen

Achtung: Dies hat Einfluss auf den TLS-Handshake

Da der Exchange Server nun keinen "Namen" kennt sondern sich auf IP-Adressen verbindet, kann er natürlich keine TLS-Zertifikat prüfen. Bei SMTP gibt es natürlich keine "HostHeader" wie bei HTTP und SNI wird bei SMTP eigentlich auch nicht verwendet aber ich muss schon temporär eine "strenge TLS Prüfung" abschalten und auf "OpportunisticTLS" reduzieren.

Eine zweite Option wäre der direkte Versand vom eigenen Mailserver ins Internet unter Umgehung des vorgelagerten Spamfilters gewesen. Ich könnte in Exchange Online den hier angelegten Connector "Outbound Internet via Hornet" einfach deaktivieren oder das Routing von Smarthost auf MX-Record umstellen. Exchange Online würde dann direkt die Mails an die Ziele senden. Denken Sie dabei aber Einschränkungen:

  • Keine Mehrwertfunktionen von des 3rd Party Produkts
    Ich denke an Verschlüsselung (SMIME), Compliance-Archive, Adress-Rewriting, Disclaimer, DKIM-Signatur etc., die oft durch solche Produkte neben dem Spamfilter mit angeboten werden.
  • SPF-Record
    Denken Sie daran, das Sie für den Eigenversand ihre ausgehenden Server im SPF-Eintrag inkludieren müssen.
  • TLS
    Sie kommen bei der Gegenstelle mit ihrem eigenen Mailserver an, der eine andere IP-Adresse, einen anderen Namen und ein anderes Zertifikat hat. Gegenstellen, die das Zertifikat prüfen, könnten die Mail ablehnen.

Einige Dinge, wie z.B. den SPF-Record können Sie schon proaktiv mit den Notfall-Servern versehen oder den TTL ausreichend Kurz (z.B. 5 Minuten) setzen, um schnell reagieren zu können.

Workaround Eingehend

Die Gegenrichtung ist nicht so einfach zu lösen. Der MX-Record der Kundendomain geht ja direkt auf die Server von Hornetsecurity.

PS C:\> resolve-dnsname -Type MX  example.com | ft -AutoSize

Name      Type TTL Section NameExchange             Preference
----      ---- --- ------- ------------             ----------
example.com MX   50  Answer  mx01.Hornetsecurity.com  10
example.com MX   50  Answer  mx02.Hornetsecurity.com  20
example.com MX   50  Answer  mx03.Hornetsecurity.com  30
example.com MX   50  Answer  mx04.Hornetsecurity.com  40

Da die Domain "Hornetsecurity.com" nicht erreichbar ist, werden die Mails auch nicht aufgelöst. Die eigentlichen Mailserver von Hornetsecurity waren aber weiter über Port 25 aus dem Internet erreichbar. Auch wenn ich das aus der Ferne nicht zuverlässig verifizieren kann, dürfte die eigentliche SMTP-Plattform weiter zur Verfügung gestanden haben. Sie hatte nur leider nichts mehr zu tun.

Sie haben aber die Hoheit über ihren DNS-Eintrag und können diesen auf einen anderen Server verweisen lassen. Das könnte direkt ihr eigener Mailserver, z.B. Exchange Online, sein, der dann natürlich Mails aus dem Internet annehmen muss und sich auch mit einem anderen Zertifikat meldet. Sie könnten aber auch einfach einen eigenen Namen definieren, der auf die gleiche IP-Adresse verweist, auf die auch bisher ihr MX-Record über die "mx01.Hornetsecurity.com"-Namen verwiesen hat. Dennoch gibt es auch hier einige Punkte zu beachten.

  • DNS-TTL
    Prüfen Sie heute einfach mal den TTL ihres MX-Eintrags. Kürzere aber nicht zu kurze Zeiten erlauben eine schnelle flexible Reaktion. Microsoft hat einen TTLS von 400,  Webhosting bei IONOS nutzt 3600Sek und HostEurope schlägt 600Sek als Default vor. Wer hier also noch 86400 (1 Tag) nutzt, sollte eine Änderung überlegen.
  • TLS-Probleme
    Der Wechsel des Mailservers bedeutet auch hier einen neuen Namen mit einem anderen Zertifikat. Wenn Partner-Connectoren auf den Namen gehen, dann könnte die Zertifikatprüfung fehlschlagen.
  • 3rd-Party-Mehrwerte
    Mit der Umgebung des vorgelagerten Systeme bekommen Sie zwar wieder viele Mails aber verlieren alle Funktionen solcher Zusatzprodukte wie Adressumschreibungen, erweiterte Spam/Antivirus-Prüfungen, Partnerconnectoren, Compliance-Funktionen und Verschlüsselung (SMIME etc.)
  • Firewall/Security
    Wenn Sie ihren Mailserver selbst betreiben, dann müssen Sie diesen ggfls. erst noch erreichbar machen. Bislang konnten Sie eingehende Verbindungen auf die IP-Adressen des 3rd-Party-Systems beschränken. Eine Risikoabschätzung und Konfigurationsänderung ist wichtig

Es hilft nichts, wenn Sie einen Großteil ihrer Mails nun wieder erhalten aber Spezialfälle nicht mehr funktionieren. Insbesondere Adressumschreibungen, Archivfunktionen oder SMIME sind hier kritisch.

status.hornet-security.com

Da die Domain "Hornetsecurity.com" in Gänze nicht auflösbar war, konnten natürlich nicht nur die Mailserver nicht weiter erreicht werden. Auch die Status-Seite war nicht erreichbar. Selbst wenn ich den realen Server noch ermitteln konnte, war ein Zugriff nicht möglich:

Sie sehen gut, dass Hornetsecurity hier den Dienstleister "status.io" nutzt, der die Domain hostedstatus.com betreibt. Leider geht der Zugriff auf Cloudflare und ohne den passenden Hostheader kann Cloudflare die Instanz nicht finden.

Das ist natürlich schon schade. Nachdem langsam wieder die DNS-Einträge verfügbar wurden, konnten sie den Status einsehen:


https://status.Hornetsecurity.com/pages/incident/591aaa7fe69f388425000fda/6662bd048e8fa2174e40ae4d

Wobei der Titel natürlich schon nur einen Teil der Auswirkungen beschreibt. Sicher ist es Anwender und Administratoren beim Zugriff auf das Admin-Portal aufgefallen, dass die Namen nicht mehr auflösbar waren. Dass damit auch die Support(at)Hornetsecurity.com betroffen war, beschreibt aber nicht mal ansatzweise die Tragweite des Problems. Im Grunde waren alle Produkte unter der Domain "Hornetsecurity.com" nicht oder nur teilweise ansprechbar und für das Mailrouting haben Kunden noch eine Empfehlung bekommen, wie Sie ihrerseits das Problem reduzieren können:

Hornetsecurity hat einfach ihre weitere Domain "Antispameurope.com" dazu genutzt, die Services erreichbar zu machen. Es blieb aber natürlich den Kunden überlassen, die Konfiguration der eigenen Mailserver auf das neue Relay und die MX-Record entsprechend anzupassen.

Aus anderen Incidents anderer Firmen habe ich aber schon gelernt, dass eh immer nur das zugegeben oder beschrieben wird, was eh schon alle rausgefunden haben. Interessant wäre es, wenn Hornetsecurity mit etwas Abstand den kompletten Vorgang in aller Ruhe beschreibt.

Übrigens habe ich nach der Erreichbarkeit der Domain die Webseiten www.Hornetsecurity.com und https://support.horntesecurity.com besucht. Am 7. Jun 2024 gab es um 18:00 keinerlei Hinweis auf die meiner Sicht schon größeren Störung. Ich weiß nicht, wie viele Administratoren nun im Wochenende weiter auf ihrer Seite nach einem Fehler suchen oder die Scherben zusammenkehren. Es sollte nur wenige Minuten dauern, einen Hinweis zu addieren.

Zwischenstand

Mittelweile sind einige Stunden vergangen und die neuen DNS-Einträge für die DNS-Zone/Domain "Hortnetsecurity.com" haben sie wieder geändert. Neben dem eigenen DNS-Server ist nun ein Server von HostEurope.de, der gleiche Provider, auf dem im Jahr 2024 auch die MSXFAQ:DE läuft, dazu gekommen.

Ob das schon immer so geplant war oder HostEurope.de nun als Domainregistrar eingesprungen ist, wird die Zukunft zeigen. Als Net at Work seine Domain "netatwork.de" vor vielen Jahrzehnten aufgebaut hat, habe ich auch noch einen lokalen DNS-Server als "Primary Server" betrieben und beim DENIC als Verweis eintragen lassen. Später war es dann ein "Hidden Primary", bei dem der Zugangsprovider die Zone von meinem DNS-Server bezogen hat aber nach extern als Nameserver publiziert wurde. Heute betreiben die meisten Firmen ihre DNS-Zonen direkt bei einem darauf spezialisierten Provider. Es ist dann immer noch möglich über Geo-DNS / Pinpoint DNS ja Unterzonen oder sogar einzelne Hosts über andere DNS-Server zu betreiben und die offizielle Zone für die statischen Einträge für Webseiten, MX-Record, SPF-Einträge etc. zu betreiben.

MXTOOLBox ist aber immer noch nicht ganz zufrieden:

Da scheint es noch einen Verweis zu einem "Primary" zu geben und der TTL ist natürlich auch noch viel zu niedrig für einen DNS-Server. Da schaue ich dann später noch mal nach. Ich denke, dass Hornetsecurity nun erst mal etwas Ruhe einkehren lassen wird und nach dem Wochenende mit Ruhe den Vorfall noch einmal aufarbeitet

Einige Stunden später hat Hornetsecurity das Problem als "beseitigt" gemeldet und alle Dienste sollten wieder funktionieren. Die temporär addierten Server von "antispameurope.de" könnten die Kunden auch wieder entfernen.

Status 19. Jun 2024

Mittlerweile hat sich noch einmal eine Änderung ergeben. Die Domain wird nun vom den DNS Servern bei Cloudflare gehostet.

Es fand also wieder ein Umzug statt, der aber diesmal zumindest nach meinen Informationen ohne weitere Bauchschmerzen über die Bühne gegangen ist. Technisch ist es ja auch einfach

  1. Sie aktivieren eine aktuelle Zone beim neuen DNS-Provider
  2. Man ändert die DNS-Delegation auf den neuen Provider
  3. Dann muss man mindestens die TTL-Zeit abwarten, bis alle Systeme im Internet die neue Delegierung kennen
  4. Zuletzt entfernt man die Zone auf dem alten Provider

Beiden Schritten 1-2 unterstützt sie ihr neuer Provider aber die Wartezeit bei 3 ehe sie dann die Kündigung bei 4 aussprechen, müssen Sie schon selbst einhalten.

Zweite Domain als Lösung?

Wenn die "Nichtauflösbarkeit" einer Domain so schwerwiegende Konsequenzen hat, dann habe ich mir überlegt, ob vielleicht zwei Domains das Problem entschärfen. Ich habe daher in Exchange Online einen neuen Outbound-Connector für meine Testdomain "lyncfaq.de" angelegt und zwei Smarthosts als Ziel hinterlegt:

  • Smarthost1: "www.microsoft.com" ist per DNS auflösbar aber nicht über Port 25 erreichbar
  • Smarthost2: "mail.gibtesnicht.tld" ist NICHT per DNS auflösbar

Ich habe dann mehrere an eine Adresse in der Domain "Lyncfaq.de" gesendet und auch diese Mails kamen alle mit der bekannten Fehlermeldung zurück. Sobald Exchange Online bei einer Namensauflösung auf einen NXDOMAIN-Ergebnis läuft, wir die Mail sofort mit einem NDR gelöscht. Das steht auch so in der RFC drin


RFC 5321 https://datatracker.ietf.org/doc/html/rfc5321#section-5.1

Das finde ich etwas übertrieben, denn es kann ja schon mal passieren und speziell bei der Neueintragung einer Domain könnte die negative Antwort durchaus noch einige Stunden in den DNS-Servern der Welt vorliegen. Vielleicht sollten die Mailserver wirklich mal dazu übergehen ,dass ein NXDOMAIN keine sofortige Unzustellbarkeit bedeutet.

Lernkurve

Was lernen wir nun aus dem Vorfall? Wir wissen nicht, wer etwas falsch gemacht hat aber der Umzug einer DNS-Zone zu einem anderen DNS-Provider und die damit verbundene Änderung der Konfiguration bei der darüber liegenden Zone bedarf einer guten Abstimmung zwischen den beiden Providern. Schließlich muss der neue Provider die komplette Zone bei sich bereitstellen, obwohl er noch nicht autoritativ ist. Der abgebende Provider darf seine DNS-Dienste aber erst abschalten, wenn die Zone auch in der darüber liegenden Zone "com" auf den neuen Provider verweist UND die Daten im Cache (Stichwort TTL) im Internet aktualisiert wurden. Ich vermute, dass der Umzug angestoßen wurde aber durch Verzögerungen die Übernahme länger gedauert hat und domaincontrol.com irgendwann seien Service eingestellt hat. Ich bin sicher, dass dies noch eine hitzige Diskussion zwischen Domaincontrol, HostEurope und Hornetsecurity gibt. Schließlich könnten Kunden die Störung mit Schadenersatzforderungen verbinden.

Ich nehme aber mal ein paar Stichpunkte mit, die ich hier aufführen möchte.

  • TTL anpassen
    Bei meinem Kunden hatten der MX-Record und der SPF-Eintrag einen TTL von 86400 Sekunden (1 Tag) das ist definitiv zu lang für solche Dienste. Wir haben keine ISDN/Datex-P-Leitungen mehr, bei denen jedes Bit zählt und ein deutlich kürzerer TTL schafft Handlungsspielraum.
  • Zwei Domains
    Klar ist eine primäre wichtige Domain als Markenzeichen und zum Betrieb optimal, wenn sie denn erreichbar ist. Wenn aber, wie hier, z.B. der DNS-Provider ein Problem hat oder die Domain aufgrund von Netzwerkstörungen, Vertragsproblemen etc. gestört ist, dann kann eine zweite komplett unabhängige Domain (andere TopLevel-TLD, anderer Provider) helfen. Was hindert mich, denn heute schon als Smarthost statt einem Server einfach zwei Server auf unterschiedlichen Domains einzutragen. Für Dienste wie SMTP ist dies kein Problem. Natürlich müssen Administratoren, die auf eine bekannte Portal-URL gehen, dann erst einmal die andere URL nutzen.
  • Alternative Meldewege
    Wenn die eigene primäre Domain komplett unerreichbar ist, kann ich auch per Mail oder Webseite nicht mehr kommunizieren. Das war gut zu sehen, dass selbst https://status.Hornetsecurity.de nicht mehr erreichbar war, obwohl der Service sicher funktioniert hat. Ich habe nun nicht kontrolliert, ob Hornetsecurity eine Telegram, LinkedIN, Twitter/X oder andere Plattform aktiv genutzt hat oder anderweitig alle Kunden schnell informieren kann. Es ist natürlich wichtig, dass eine Firma auch alle Ansprechpartner der Kunden z.B. über ein unabhängiges Mailsystem für Updates oder Konfigurationsänderungen erreichen kann. Das eigene System funktioniert eventuell nicht mehr.
  • DNS-Überwachung
    Zwischen der ersten Fehlermeldung um 9:55 (CET) und der Meldung über die DNS-Probleme gegen 13:41 CET ist ziemlich viel Zeit vergangen. Ich habe in wenigen Minuten die oben aufgeführten Analysen gemacht, das Problem mit der Zone ermitteln und mit dem Kunden nach Alternativen gesucht. Ich lerne daraus, dass ich noch viel mehr Sensoren für DNS-Abfragen anlegen muss. Es reicht nicht nur die eigenen Namen von intern zu prüfen, sondern vielleicht sollten wir auch die komplette Kette von den Root-Servern über die TLD-Betreiber und den DNS-Provider von verschiedenen Standorten aus durchprüfen. Der Verlust der Namensauflösung der Zone "Hornetsecurity.com" hat hoffentlich nicht fast 4 Stunden gedauert.
  • NXDOMAIN
    Der Ausfall zeigt aber auch noch einmal deutlich die Problematik einer NXDOMAIN, d.h. wenn alle Hosts in einer Konfiguration, sei es MX-Record oder Smarthost nicht auflösbar sind. Der entsprechende Client geht dann einfach von einer "Nichtexistenz" statt einer "temporären Störung" aus.

Ich gebe unumwunden zu, dass der Verlust der Namensauflösung zu einer Domain mir in der Tragweite auch nicht bekannt war. Ich wäre davon ausgegangen, dass die Mailserver es einfach wieder versuchen. Das hake ich mal unter "Jeden Tag was dazu lernen" ab

Das bedeutet im Umkehrschluss aber, dass der Verlust einer Domain durch eine "Nicht-Auflösbarkeit" ein ernstzunehmendes Problem ist und alle Anbieter von Diensten in der Cloud diesen Fall besonders gut beachten müssen. Oder Sie passen dort, wo es in ihrer Verantwortung liegt, ihre Software entsprechend an. Bei den Mailservern der Welt wird dies schwierig sein und niemand möchte auf IP-Adressen als Smarthost wechseln, denn da gibt es dann wieder die Probleme mit TLS-Prüfungen.

Weitere Links