Am Abend des 5. Mai 2026 liefen in tausenden deutschen Online-Shops die Server einwandfrei: Die Shop-Software antwortete, die Datenbank war gesund, das TLS-Zertifikat gültig, die Bestellstrecke intakt. Trotzdem kam ein erheblicher Teil der Kunden nicht mehr an -- der Browser meldete schlicht, die Seite sei nicht erreichbar. Die Ursache lag nicht in einem einzelnen Shop, sondern eine Ebene darunter: In der .de-Zone schlug ein Zone-Signing-Key-Rollover fehl. Ab 21:43 Uhr (heise online) signierte die Registry mit einem Schlüssel, dessen öffentlicher Teil nicht korrekt veröffentlicht war; rund drei Stunden (DENIC eG) lang lieferten DNSSEC-validierende Resolver auf Anfragen nach .de-Domains einen Fehler statt einer Adresse. Wer sein Uptime-Monitoring vom eigenen Standort aus betrieb, sah in dieser Zeit womöglich durchgehend Grün. Genau darin liegt die Lehre des Vorfalls: Die Namensauflösung ist ein eigener Wartungsgegenstand mit eigenen Fehlerbildern -- und sie gehört in ein Monitoring, das mehr prüft als einen Statuscode. Dieser Beitrag behandelt Signaturkette, Domain-Locks, Ablaufdaten, TTL-Planung, resolver-differenzierte Überwachung und ein Runbook für Störungen, die außerhalb des eigenen Verantwortungsbereichs entstehen.
Die Nacht, in der alles lief und nichts ankam
Der Ablauf ist gut dokumentiert und lohnt die genaue Betrachtung, weil er ein Fehlerbild zeigt, das in keinem klassischen Wartungsplan vorkommt. Am 2. Mai 2026 (heise online) begann bei der DENIC der planmäßige Wechsel des Zone Signing Key für die .de-Zone. Ein neuer öffentlicher Schlüssel mit der ID 33834 (heise online) wurde veröffentlicht -- drei Tage, bevor er zum ersten Mal zum Signieren verwendet wurde. Diese Wartezeit ist bewusst so gewählt: Resolver in aller Welt sollen den neuen Schlüssel kennen, bevor Signaturen mit ihm auftauchen. Am 5. Mai um 21:43 Uhr (heise online) tauchte Schlüssel 33834 erstmals in einer Signatur für den SOA-Record der .de-Zone auf. Von diesem Moment an war die Signaturkette gebrochen.
Die Ursache war weder ein Angriff noch ein Ausfall von Hardware, sondern ein Fehler in selbst entwickeltem Code. Statt ein einziges Schlüsselpaar zu erzeugen und dieses in alle angeschlossenen Hardware-Sicherheitsmodule einzuspielen, erzeugte die Software pro HSM ein eigenes Schlüsselpaar (DENIC eG) -- drei verschiedene private Schlüssel, alle mit derselben Kennung 33834, aber nur einer davon passend zum veröffentlichten öffentlichen Schlüssel. Da alle Signiersysteme im Einsatz waren, lieferte die Zone Signaturen aus zwei nicht passenden und einem passenden Schlüssel. Im Ergebnis waren nur noch etwa ein Drittel (DENIC eG) der RRSIG-Records validierbar. Die betroffene Signierumgebung war erst im April 2026 (DENIC eG) als dritte Generation in Betrieb genommen worden. Der fehlerhafte Codeabschnitt war laut DENIC "nicht vollständig von den Testszenarien abgedeckt" (DENIC eG) und fiel deshalb weder in Testläufen noch im kalten Parallelbetrieb vor der Inbetriebnahme auf.
Der Ausfall betraf auch Shops ganz ohne DNSSEC
Die Wiederherstellung dauerte. Erst gegen 01:17 Uhr (heise online) fiel die Entscheidung zum Rollback auf den vorherigen Schlüssel 32911; um 00:08 Uhr (DENIC eG) hatte DENIC bereits die Verteilung einer korrigierten Zone eingeleitet, und um 01:15 Uhr (DENIC eG) war der Betriebszustand vor dem Ausfall wieder vollständig hergestellt. Als Konsequenz kündigte DENIC im Abschlussbericht vom 11. Juni 2026 (DENIC eG) unter anderem erweiterte Alarmierung, beschleunigte Zonen-Backups, eine Validierung der Zone vor der Auslieferung, die Aussetzung weiterer ZSK-Rollover bis zur Verbesserung der Verfahren sowie eine externe Sicherheits- und Prozessanalyse an. Für Shop-Betreiber ist die entscheidende Erkenntnis eine andere: Zwischen dem eigenen Server und dem Kunden liegt eine Infrastruktur, die man nicht kontrolliert, deren Ausfall aber wie ein Totalausfall des eigenen Shops wirkt.
Warum das Uptime-Dashboard grün blieb
Die eigentliche Tücke des Vorfalls war seine Ungleichverteilung. Ob ein Kunde den Shop erreichte, hing nicht vom Shop ab, sondern davon, welchen DNS-Resolver sein Gerät benutzte. Resolver mit aktiver DNSSEC-Validierung prüfen jede Antwort gegen die Signaturkette. Schlägt die Prüfung fehl, gilt die Antwort als "Bogus" und wird verworfen -- der Client bekommt SERVFAIL, also die Aussage, die Auflösung sei gescheitert. Resolver ohne Validierung überspringen diese Prüfung und reichen die Antwort durch. Für sie war der Shop die ganze Zeit über erreichbar. "Nicht validierende Resolver" (DENIC eG) setzten den Betrieb normal fort.
Damit zerfiel die Kundschaft in zwei Gruppen, ohne dass es dafür ein technisches Signal im Shop gab. Wer einen validierenden Unternehmens- oder öffentlichen Resolver nutzte, sah einen Totalausfall. Wer den Standard-Resolver seines Anschlusses nutzte und dieser nicht validierte, kaufte weiter. Erschwerend kam hinzu, dass einige große Resolver-Betreiber "vorübergehend die Validierung von .de-Domains ausgesetzt" (DENIC eG) haben -- was die Auswirkungen für ihre Nutzer abmilderte, aber die Diagnose für Betreiber zusätzlich verwirrte: Dieselbe Domain war je nach Abfrageweg und Uhrzeit erreichbar oder nicht.
| Prüfebene | Frage | Antwort am 5. Mai 2026 | Blinder Fleck |
|---|---|---|---|
| HTTP-Uptime-Check vom eigenen Standort | Antwortet der Server? | Grün -- HTTP 200 | Sagt nichts darüber, ob die Domain für den Kunden auflösbar ist |
| HTTP-Check über nicht validierenden Resolver | Antwortet der Server? | Grün -- HTTP 200 | Prüft die Signaturkette nicht und meldet den Bruch nicht |
| DNS-Check über validierenden Resolver | Ist die Antwort kryptografisch belegbar? | Rot -- SERVFAIL | Erkennt den Bruch, sagt aber nichts über den Shop selbst |
| Kette-und-Ablauf-Check | Passen DS, DNSKEY und RRSIG zusammen und wie lange noch? | Rot -- Kette gebrochen | Braucht eigene Prüflogik statt Statuscode |
Daraus folgt eine unbequeme, aber nützliche Regel: Ein einzelner Check von einem einzelnen Ort mit einem einzelnen Resolver beschreibt die Erreichbarkeit für genau einen Abfrageweg -- nicht für den Markt. Wer wissen will, ob sein Shop verkaufsfähig ist, muss den Weg der Kunden nachbilden, und dazu gehört die Resolver-Frage ebenso wie Region und Endgerät. Wie ein solides HTTP-Fundament dafür aussieht, beschreibt der Beitrag zum Uptime-Monitoring einrichten; die hier beschriebene DNS-Ebene liegt darunter und wird davon nicht abgedeckt.
Die Signaturkette als Wartungsgegenstand
DNSSEC ist kein exotisches Extra. Die IETF hat mit RFC 9364 (IETF RFC 9364), zugleich als BCP 237 im Februar 2023 veröffentlicht, festgehalten, dass der Einsatz von DNSSEC zur Ursprungsauthentifizierung von DNS-Daten die aktuelle bewährte Praxis darstellt. Auch das BSI empfiehlt im IT-Grundschutz-Baustein APP.3.6 DNS-Server (BSI), DNS-Informationen mit DNSSEC abzusichern. Die Technik löst ein reales Problem: Ohne Signatur lässt sich eine DNS-Antwort fälschen, und wer die Antwort fälscht, lenkt den Kunden auf einen fremden Server um, obwohl in der Adresszeile die richtige Domain steht. Der Preis dafür ist, dass eine kaputte Signatur strenger wirkt als gar keine Signatur -- sie führt zum Verwerfen der Antwort statt zu einer Warnung.
Genau deshalb gehört die Kette in die Wartung. Sie besteht aus wenigen Bausteinen, die nach jeder Änderung an Registrar, DNS-Betreiber oder Hosting zusammenpassen müssen. Der gefährlichste Moment ist nicht der Normalbetrieb, sondern der Wechsel: Ein Providerwechsel, bei dem der DS-Record in der übergeordneten Zone auf einen Schlüssel zeigt, den der neue Betreiber gar nicht mehr verwendet, macht die Domain für validierende Resolver unerreichbar -- bei technisch einwandfreiem Shop.
DNSKEY
Der öffentliche Schlüssel der Zone. Er muss zu dem privaten Schlüssel passen, mit dem tatsächlich signiert wird. Genau hier lag der Bruch am 5. Mai: veröffentlicht war ein Schlüssel, signiert wurde teils mit anderen.
RRSIG
Die Signatur über einen Datensatz. Sie hat ein Ablaufdatum. Läuft sie ab, ohne erneuert zu werden, verwerfen validierende Resolver die Antwort -- ein stiller Ausfall mit Zeitzünder.
DS-Record
Der Fingerabdruck des Schlüssels, hinterlegt in der übergeordneten Zone beim Registrar. Er verbindet die eigene Zone mit der Vertrauenskette. Nach jedem Schlüsselwechsel muss er nachgezogen werden.
NSEC3
Der kryptografische Beweis, dass ein Eintrag nicht existiert. Bricht dieser Beweis, wird auch die Abwesenheit eines DS-Records unbelegbar -- was am 5. Mai unsignierte Domains mit in den Ausfall zog.
Schlüsselwechsel
Rollover von ZSK und KSK sind Routine, aber fehleranfällig. Neue Schlüssel gehören veröffentlicht, bevor sie signieren, und alte bleiben gültig, bis die letzte zwischengespeicherte Signatur abgelaufen ist.
Providerwechsel
Der kritischste Vorgang überhaupt. DNS-Betreiber, Registrar und DS-Record müssen in der richtigen Reihenfolge umgestellt werden. Ein DS-Record, der auf einen nicht mehr genutzten Schlüssel zeigt, sperrt die eigene Domain aus.
Prüfpunkt nach jeder Änderung an Domain oder Hosting
Registrar- und Registry-Lock: die Domain gegen Änderungen sperren
Die zweite Baustelle der DNS-Wartung hat nichts mit Kryptografie zu tun, sondern mit Zugriffsrechten. Eine Domain ist kein Besitz im physischen Sinne, sondern ein Eintrag in einer Datenbank -- und wer diesen Eintrag ändern darf, kontrolliert den Shop. Ein übernommener Registrar-Zugang genügt, um Nameserver umzubiegen, Mail auf fremde Server zu leiten und die Domain zu transferieren. Der Shop läuft dabei weiter; er ist nur nicht mehr über seine eigene Adresse erreichbar.
Die ICANN-Sicherheitsgremien beschreiben dafür seit Jahren ein abgestuftes Vorgehen. Locks sind formal Statuscodes, die "Änderungen an Domain-Registrierungen verhindern und Versuche blockieren, Domains zu transferieren oder zu löschen" (ICANN, SAC 044). Darüber hinaus bieten mehrere Registry-Betreiber einen Registry-Lock an, der "zusätzlich zu den Lock-Diensten der Registrare" (ICANN) greift und häufig eine manuelle Freigabe vorsieht -- also einen Menschen, der eine Änderung außerhalb des automatisierten Wegs bestätigt. Genau diese Reibung ist der Zweck: Sie kostet ein paar Stunden bei einem geplanten Umzug und verhindert eine Änderung, die niemand beauftragt hat.
| Schutzebene | Wirkt gegen | Aufhebbar durch | Empfohlen für |
|---|---|---|---|
| Registrar-Lock (Client-Statuscodes) | unbeabsichtigte Transfers und Löschungen | Inhaber im Registrar-Portal, meist sofort | jede produktiv genutzte Domain |
| Registry-Lock | Änderungen über einen übernommenen Registrar-Zugang | definierten Prozess mit manueller Freigabe | Shop-, Zahlungs- und Mail-Domains |
| Zwei-Faktor am Registrar-Konto | Zugangsübernahme per Passwort allein | Inhaber mit zweitem Faktor | jedes Konto mit Domain-Hoheit |
| Getrennte Konten je Zweck | Kollateralschaden bei einem kompromittierten Zugang | Rollen- und Rechtevergabe | Agenturen und größere Teams |
Die Priorisierung folgt dem Schaden, nicht dem Traffic. Eine Domain, über die Zahlungen abgewickelt oder Bestellbestätigungen versendet werden, verdient den höheren Schutz -- auch wenn sie weniger Besucher hat als die Hauptdomain. Wer seine Mail-Records ohnehin pflegt, kennt das Muster bereits aus dem Beitrag zu DMARC und der Zustellbarkeit von Shop-Mails: Dort geht es um die Frage, wer in Ihrem Namen senden darf. Hier geht es um die Ebene darüber -- wer überhaupt bestimmt, wo Ihre Domain hinzeigt. Dass Zugänge die eigentliche Angriffsfläche sind, gilt für Domains genauso wie für die Lieferkette einer Shop-Installation; die Parallele beschreibt der Beitrag zu Supply-Chain-Angriffen über Shop-Abhängigkeiten.
Ablaufdaten: die stillsten Ausfälle im Kalender
Domains laufen ab. Das klingt trivial und ist trotzdem ein regelmäßiger Grund für Totalausfälle, weil das Ablaufdatum an einem Ort liegt, den niemand überwacht: in einer Registrar-Oberfläche, verknüpft mit einer Kreditkarte, die vor zwei Jahren neu ausgestellt wurde, und einer Benachrichtigungsadresse, die auf einen ausgeschiedenen Mitarbeiter zeigt. Bei 18 Millionen (DENIC eG, Juni 2026) registrierten .de-Domains ist die Verwaltungslast in vielen Unternehmen über Jahre gewachsen und selten dokumentiert. Die ICANN-Empfehlungen für Registranten betonen deshalb die Pflege der Kontaktdaten des Registrierungskontos als eigene Schutzmaßnahme (ICANN, SAC 044) -- weil eine Warnmail, die niemand liest, keine Warnung ist.
- Ablaufdatum jeder Domain maschinell überwacht, mit Vorlauf von mindestens 60 Tagen und Eskalation an eine Rolle, nicht an eine Person.
- Zahlungsmittel beim Registrar auf Gültigkeit geprüft -- eine abgelaufene Karte verwandelt eine automatische Verlängerung in eine automatische Löschung.
- Kontaktadressen des Registrierungskontos auf eine Verteiler- oder Rollenadresse gelegt, die den Weggang einzelner Mitarbeiter überdauert.
- Inhaberdaten aktuell und korrekt -- bei einem Streitfall oder einer Wiederherstellung zählt, wer nachweislich eingetragen ist.
- Nebendomains, Tippfehler-Varianten und alte Kampagnendomains inventarisiert: Sie leiten oft auf den Shop und fallen bei Ablauf in fremde Hände.
- Ablauf der DNSSEC-Signaturen und Gültigkeit des DS-Records in derselben Überwachung wie Domain- und Zertifikatslaufzeiten.
Ein Inventar ist die Voraussetzung, nicht die Kür
TTL-Planung vor Migrationen
Die Time to Live eines DNS-Records bestimmt, wie lange Resolver eine Antwort zwischenspeichern dürfen. Im Normalbetrieb ist ein hoher Wert angenehm: weniger Anfragen, schnellere Antworten, geringere Last. Bei einer Migration wird derselbe Wert zum Problem, denn er bestimmt auch, wie lange die Welt noch auf den alten Server zeigt, nachdem Sie längst umgestellt haben. Wer mit einer TTL von 24 Stunden umzieht, hat einen Tag lang zwei aktive Umgebungen -- und Bestellungen, die auf dem alten Server landen.
Die Reihenfolge ist deshalb wichtiger als die Geschwindigkeit. Eine geordnete Umstellung senkt die TTL, wartet die alte TTL ab, stellt um, beobachtet und hebt den Wert erst danach wieder an. Der DENIC-Vorfall zeigt die gleiche Mechanik aus der anderen Richtung: Weil Zwischenspeicher die alte, gültige Antwort noch eine Weile hielten, traf der Fehler nicht alle Nutzer gleichzeitig, sondern sickerte über Minuten ein -- und verschwand nach der Korrektur ebenso ungleichmäßig wieder.
- Mindestens 48 Stunden vor dem geplanten Umzug die TTL der betroffenen Records auf einen niedrigen Wert senken, etwa 300 Sekunden.
- Die alte, hohe TTL vollständig ablaufen lassen, bevor die eigentliche Umstellung beginnt -- sonst wirkt die Senkung noch gar nicht.
- Zielumgebung vor der Umstellung über ihre IP oder einen temporären Namen fachlich testen, inklusive Bestellstrecke und Zahlungsrückleitung.
- Bei signierten Zonen den DS-Record und den Schlüsselwechsel abstimmen, bevor der Nameserver wechselt -- nicht danach.
- Umstellen und beide Umgebungen parallel beobachten, solange noch Anfragen auf der alten Adresse eintreffen.
- TTL erst wieder anheben, wenn die Umstellung fachlich abgenommen ist und der Rückweg nicht mehr gebraucht wird.
TTL-Senkung gehört in die Fensterplanung
Resolver-differenziertes Monitoring statt eines einzelnen Checks
Wenn ein einzelner Check die Realität nicht abbildet, lautet die Antwort nicht "mehr Checks", sondern "andere Fragen". Die DNS-Ebene braucht Prüfungen, die den Unterschied zwischen validierenden und nicht validierenden Auflösungswegen sichtbar machen -- sonst wiederholt sich das Muster vom 5. Mai: Das Dashboard bleibt grün, während ein Teil der Kunden den Shop nicht findet. Drei Prüfungen decken den Kern ab, und keine davon ist ein HTTP-Statuscode.
Zwei Auflösungswege parallel
Dieselbe Domain über einen validierenden und einen nicht validierenden Resolver abfragen. Weichen die Ergebnisse voneinander ab, liegt der Fehler in der Signaturkette -- und zwar unabhängig davon, ob der Shop antwortet.
Kette und Restlaufzeit
Prüfen, ob DS-Record, DNSKEY und RRSIG zusammenpassen, und wie lange die aktuellen Signaturen noch gültig sind. Diese Prüfung erkennt einen Bruch nach einem Providerwechsel, bevor ihn ein Kunde meldet.
Mehrere Regionen
Auflösung aus verschiedenen Netzen abfragen. Regionale Unterschiede in der Resolver-Landschaft führen dazu, dass ein Fehler an einem Ort sofort sichtbar und an einem anderen unsichtbar ist.
Ablaufdaten als Metrik
Domain-Ablauf, Signaturlaufzeit und Zertifikatslaufzeit als überwachte Werte mit Vorlauf-Schwellen behandeln -- nicht als Kalendereintrag, der beim Wechsel der Zuständigkeit verloren geht.
Lock- und Record-Drift
Statuscodes, Nameserver-Einträge und zentrale Records regelmäßig gegen einen Sollstand vergleichen. Eine unerwartete Änderung ist entweder ein Fehler oder ein Angriff -- beides will man am selben Tag wissen.
Alarmweg außerhalb der Domain
Alarmierung, die nicht über die überwachte Domain läuft. Wenn die Namensauflösung fällt, fällt auch die Mail an mail@ihre-domain.de -- die Benachrichtigung braucht einen unabhängigen Weg.
Der letzte Punkt wird regelmäßig übersehen und war am 5. Mai besonders relevant: Ein Alarmierungsweg, der selbst von der gestörten Zone abhängt, schweigt genau dann, wenn er gebraucht wird. Dieselbe Logik gilt für die Statusseite, auf die man Kunden verweisen möchte -- liegt sie unter derselben Domain, ist sie im Ernstfall ebenfalls unerreichbar. Wie sich Prüfungen bis in die Bestellstrecke hinein fortsetzen, zeigt der Beitrag zum Checkout- und Transaktions-Monitoring; die DNS-Ebene ist die Stufe davor, denn ohne Auflösung erreicht kein Kunde den Checkout. Zusammen mit der Überwachung der SSL-Zertifikate ergibt sich eine durchgehende Kette von der Namensauflösung bis zur verschlüsselten Verbindung.
Ein grünes Uptime-Signal beweist, dass Ihr Server antwortet -- nicht, dass Ihre Kunden ihn finden.
Runbook für Störungen, die nicht Ihnen gehören
Der unangenehmste Teil des DENIC-Vorfalls war die Ohnmacht. Es gab keinen Schalter im eigenen Shop, der das Problem behoben hätte, denn der Fehler lag in einer Zone, die niemand außer der Registry ändern kann. Trotzdem ist der Unterschied zwischen vorbereitet und unvorbereitet erheblich -- er entscheidet, ob Sie zwei Stunden lang die eigene Infrastruktur zerlegen oder nach zehn Minuten wissen, dass der Fehler außerhalb liegt, und den Rest der Zeit in Kommunikation investieren.
- Eingrenzen: Antwortet der Server unter seiner IP-Adresse? Wenn ja, ist der Shop gesund und das Problem liegt in der Auflösung -- weitere Suche im Shop kostet nur Zeit.
- Differenzieren: Dieselbe Domain über einen validierenden und einen nicht validierenden Resolver abfragen. Antwortet nur der nicht validierende, ist die Signaturkette der Verdächtige.
- Verorten: Betrifft es nur die eigene Domain oder auch fremde Domains derselben Endung? Sind fremde .de-Domains ebenfalls betroffen, liegt die Ursache oberhalb Ihrer Zone.
- Registry-Status prüfen: Die Statusmeldungen des Registry-Betreibers sind die verlässlichste Quelle -- DENIC informierte noch in der Nacht über die Störung und lieferte später Analyse und Abschlussbericht nach.
- Kommunizieren: Kunden und Support über einen Kanal informieren, der nicht unter der betroffenen Domain liegt. Eine ehrliche Statusmeldung ist wertvoller als der Versuch, ein fremdes Problem zu verbergen.
- Dokumentieren: Zeitpunkte, Symptome, Abfrageergebnisse und Entscheidungen mitschreiben -- für die spätere Auswertung und für Nachweise gegenüber Dritten.
Was in einer Registry-Störung nicht hilft
Der Rest ist eine Frage der Organisation: Wer erreicht wen um 22 Uhr, wer entscheidet, wer spricht mit den Kunden? Das ist dieselbe Struktur, die auch bei einem Sicherheitsvorfall trägt und die der Notfall-Support mit definierten Reaktionszeiten abbildet. Wie ein solcher Ablauf im Ernstfall aussieht, beschreibt auch der Beitrag zum Notfallplan für eine gehackte Website -- die Ursache unterscheidet sich, das Vorgehen ähnelt sich.
DNS als feste Position in der Wartung
In den meisten Wartungsverträgen kommt die DNS-Ebene nicht vor. Sie liegt zwischen den Zuständigkeiten: Der Hoster verantwortet den Server, die Agentur den Shop, der Registrar die Domain -- und die Signaturkette verantwortet niemand, bis sie bricht. Das ist keine Nachlässigkeit, sondern eine Folge der Historie: Die Ebene war lange unauffällig, und was unauffällig ist, landet in keinem Leistungsverzeichnis. Der 5. Mai 2026 hat diese Annahme korrigiert.
Praktisch bedeutet das drei Ergänzungen. Erstens ein gepflegtes Inventar aller Domains mit Registrar, DNS-Betreiber, Ablaufdatum, Lock-Status und DNSSEC-Zustand. Zweitens eine Überwachung, die die Auflösung über verschiedene Resolver prüft, die Signaturkette gegen den DS-Record abgleicht und Ablaufdaten als Metrik führt statt als Kalendereintrag -- fachlich derselbe Ansatz, der in unserem Monitoring auch für Erreichbarkeit, Zertifikate und Bestellstrecke gilt. Drittens ein hinterlegtes Vorgehen für den Fall, dass die Ursache oberhalb der eigenen Zone liegt, inklusive Alarmweg und Statuskommunikation außerhalb der betroffenen Domain.
Verbindlich wird das über die Vereinbarung, nicht über die Technik. Ein SLA-Wartungsvertrag hält fest, welche Prüfungen laufen, wie schnell reagiert wird und wer im Ernstfall entscheidet; die einzelnen Bausteine dazu sind in unseren Wartungsleistungen beschrieben. Welche Reaktionszeiten dabei realistisch und sinnvoll sind, ordnet der Beitrag zur Reaktionszeit im SLA ein. Der Anspruch ist dabei bewusst nüchtern: Eine Störung bei der Registry lässt sich von außen nicht verhindern. Aber ob Sie sie in Minuten oder in Stunden verstehen, ob Ihre Kunden eine Erklärung bekommen und ob Ihre eigene Kette nach dem nächsten Providerwechsel noch stimmt -- das liegt sehr wohl in Ihrer Hand.
Quellen und Studien