So verhindern Sie DNS-Ausfälle und abgelaufene Domains bei Kundenwebsites

HTTP-Fehler kommen mit einem Statuscode, und Serverausfälle hinterlassen Logs. Wenn DNS ausfällt, ist die Website einfach nicht mehr dort, wohin ihr Name zeigt. Besucher bekommen vom Browser die Meldung, dass die Website nicht erreichbar ist, oder sie sehen die Seite von jemand anderem.

Für Freelancer mit Kundenwebsites decken drei Ursachen fast alles ab:

• Die Domain ist abgelaufen. Die automatische Verlängerung schlug fehl, weil die hinterlegte Karte abgelaufen war, oder die Verlängerungserinnerungen gingen an eine Adresse, die niemand liest, etwa die alte Adresse des Kunden.
• Ein Eintrag ging bei einer Migration schief. Der A-Eintrag zeigt noch auf den alten Server, oder ein Tippfehler lässt ihn ins Leere zeigen.
• Die Nameserver wurden geändert. Jemand hat die Domain zu einem neuen DNS-Anbieter umgezogen oder ein Registrar-Transfer hat sie geändert, und die Einträge wurden am neuen Ort nicht neu angelegt.

Was wirklich passiert, wenn eine Domain abläuft

Für generische Domains wie .com, .net und .org legt die Expired Registration Recovery Policy der ICANN den Ablauf fest:

1. Der Registrar schickt dem eingetragenen Domaininhaber Erinnerungen, meist per E-Mail: etwa einen Monat und etwa eine Woche vor dem Ablauf und mindestens eine weitere innerhalb von fünf Tagen danach. Hat der Kunde die Domain registriert, gehen die Erinnerungen an den Kunden.
2. Nach dem Ablauf muss der Registrar den DNS-Auflösungspfad der Domain unterbrechen. Der Name löst dann entweder nicht mehr auf oder führt zur Landingpage des Registrars, die angeben muss, dass die Registrierung abgelaufen ist und wie man sie verlängert. Die Website "verschwindet" also nicht immer: Sie kann durch eine Verlängerungsseite ersetzt werden, die weiterhin lädt.
3. Verlängert niemand und wird die Registrierung gelöscht, folgt eine 30-tägige Redemption Grace Period, in der die Registry die DNS-Auflösung abschaltet. Abfragen schlagen jetzt für alle fehl, typischerweise mit NXDOMAIN ("keine solche Domain"), bis die Domain wiederhergestellt ist.

Länderdomains wie .sk, .cz, .de oder .uk folgen den Regeln ihrer eigenen Registry. Prüfen Sie daher für die Domain jedes Kunden die Bedingungen des Registrars.

Der praktische Punkt: Für eine Prüfung, die nur den Statuscode liest, kann Schritt 2 wie eine funktionierende Website aussehen.

Ein Ablauf zur Fehlersuche

Wenn ein Kunde sagt "die Website ist weg", führen Sie diese Befehle aus, bevor Sie irgendetwas anfassen. Ersetzen Sie example.com durch die Domain des Kunden.

Sehen Sie sich den Weg von den Root-Servern bis zur Antwort an und wo er abbricht:

dig +trace example.com

Vergleichen Sie die Nameserver, die bei der Registry hinterlegt sind, mit denen, die Sie erwarten:

dig +short NS example.com
whois example.com | grep -iE "name ?server|nserver"

Prüfen Sie das Ablaufdatum (der Feldname unterscheidet sich je nach Registry, und manche Länder-Registrys veröffentlichen keins):

whois example.com | grep -iE "expir"

Fragen Sie jeden autoritativen Nameserver nach seiner SOA-Seriennummer. Unterschiedliche Seriennummern bedeuten, dass ein Nameserver die neueste Zone noch nicht übernommen hat oder eine Änderung noch kopiert wird:

for ns in $(dig +short NS example.com); do echo "$ns $(dig +short SOA example.com @$ns | awk '{print $3}')"; done

Vergleichen Sie einen öffentlichen Resolver mit der autoritativen Antwort. Liefert der autoritative Server das Richtige und der öffentliche Resolver nicht, warten Sie darauf, dass ein Cache abläuft, und haben keinen falschen Eintrag vor sich:

dig +noall +answer example.com @1.1.1.1
dig +noall +answer example.com @<one of the NS names above>

Beheben Sie das Problem dann an der richtigen Stelle: eine abgelaufene Domain beim Registrar, falsche Nameserver beim Registrar, einen falschen Eintrag beim DNS-Anbieter.

Vor einer Migration: zuerst die TTL senken

Resolver behalten eine Antwort so lange, wie ihre TTL angibt. Hat der A-Eintrag eine TTL von 86400 Sekunden (ein Tag), können manche Besucher nach Ihrer Änderung noch einen Tag lang beim alten Server landen.

1. Prüfen Sie die aktuelle TTL auf dem autoritativen Server: dig +noall +answer example.com @<nameserver> (zweite Spalte).
2. Senken Sie sie mindestens eine alte TTL vor der Änderung auf 300 Sekunden, bei einer TTL von einem Tag also ein bis zwei Tage vorher.
3. Nehmen Sie die Änderung vor und bestätigen Sie sie dann auf dem autoritativen Server und auf einem öffentlichen Resolver.
4. Lassen Sie den alten Server laufen, bis die alte TTL verstrichen ist.
5. Erhöhen Sie die TTL wieder, sobald alles auf den neuen Ort zeigt.

Was Sie überwachen sollten

• Das Ablaufdatum jeder Kundendomain, mit Erinnerungen, die Sie erreichen und nicht nur den Kunden.
• Die Einträge, auf die es ankommt: den A-Eintrag (oder AAAA-Eintrag) der Website und den MX-Eintrag, wenn die E-Mail des Kunden davon abhängt.
• Den Wert dieser Einträge, nicht nur, dass es sie gibt, damit auch ein Eintrag auffällt, der auf den falschen Server zeigt.
• Die Seite selbst: In der oben beschriebenen Phase mit der Verlängerungsseite bemerkt nur eine Prüfung, die den Seiteninhalt liest, den Unterschied.

Was der DNS-Monitor und die Domain-Warnungen von Baromio abdecken

• DNS-Monitor: fragt für einen Hostnamen einen Eintragstyp ab (A, AAAA, MX, CNAME oder TXT), über den normalen Resolver auf dem Server von Baromio, so oft Ihr Plan es erlaubt: alle 5 Minuten bei Free, jede Minute bei Pro, alle 30 Sekunden bei Business. Er schlägt fehl, wenn kein Eintrag zurückkommt. Ist das Feld Erwarteter Wert ausgefüllt, schlägt er auch fehl, wenn der erste Eintrag der Antwort diesen Text nicht enthält, unabhängig von Groß- und Kleinschreibung; google.com passt also zu einem MX-Eintrag wie aspmx.l.google.com. Bei einem Namen mit mehreren A-Einträgen kann der erste wechseln. Lassen Sie den erwarteten Wert dort also leer oder verwenden Sie einen Teil, den alle gemeinsam haben.
• Was der DNS-Monitor nicht tut: Er prüft nur von einem Server aus, vergleicht weder Nameserver noch SOA-Seriennummern und testet nicht die Verbreitung über verschiedene Resolver. Dafür nutzen Sie den Ablauf oben.
• Domain-Ablauf: Aktivieren Sie Domain-Ablauf überwachen an einem HTTP- oder Keyword-Monitor (standardmäßig ausgeschaltet). Einmal am Tag liest Baromio das Ablaufdatum der Domain aus WHOIS und warnt Sie per E-Mail und über Ihre verbundenen Slack-, Discord- oder Webhook-Kanäle an den Tagen, an denen noch 30, 14 und 7 Tage übrig sind. Nach der Warnung bei 7 Tagen kommt keine weitere, betrachten Sie sie also als letzte Warnung. Die Monitor-Karte zeigt ein WHOIS-Badge mit den verbleibenden Tagen. Veröffentlicht die Registry kein Ablaufdatum, erscheint auch keins. Für Domains unter einer zweiteiligen Endung wie .co.uk funktioniert die Abfrage noch nicht; prüfen Sie diese von Hand.
• Pläne: Beides ist in jedem Plan verfügbar; Free umfasst 20 Monitore, Pro (9 EUR im Monat) 30 und Business (29 EUR im Monat) 100.

Eine Checkliste für jeden Kunden

1. Notieren Sie Registrar, DNS-Anbieter und wer die Verlängerung bezahlt.
2. Stellen Sie sicher, dass Verlängerungserinnerungen Sie erreichen und die automatische Verlängerung eine gültige Karte hat.
3. Richten Sie einen DNS-Monitor mit erwartetem Wert für den Haupteintrag der Website ein und einen weiteren für MX, wenn E-Mail wichtig ist.
4. Aktivieren Sie die Warnungen zum Domain-Ablauf am HTTP- oder Keyword-Monitor der Website.
5. Senken Sie die TTL ein bis zwei Tage vor jeder DNS-Änderung und lassen Sie den alten Server laufen, bis die alte TTL verstrichen ist.

Quellen

• ICANN, Expired Registration Recovery Policy: Zeitpunkte der Erinnerungen (2.1), Unterbrechung des DNS-Auflösungspfads und die Verlängerungs-Landingpage nach dem Ablauf (2.2), die 30-tägige Redemption Grace Period nach der Löschung mit abgeschalteter DNS-Auflösung (3.1, 3.2).