Es ist Freitagabend, 17:30 Uhr. Ein Administrator möchte schnell noch ein Wildcard-Zertifikat für die neue Firmenstruktur ausrollen. Er verlässt sich auf die Standardeinstellungen seines ACME-Clients und sieht die Meldung Let's Encrypt ACME: Preparing to Solve DNS-01 auf seinem Monitor. Er geht davon aus, dass der TXT-Record in Sekunden aktiv ist. Doch die Validierung schlägt fehl. Er versucht es erneut, und wieder schlägt es fehl. Nach dem fünften Versuch greift das Rate-Limit von Let's Encrypt. Das Ergebnis: Die gesamte Marketing-Kampagne für das Wochenende steht still, weil die Subdomains keine gültigen Zertifikate haben. Die Kosten für die Verzögerung und die Überstunden des Teams belaufen sich schnell auf mehrere tausend Euro. Ich habe dieses Szenario in den letzten Jahren bei Dutzenden von Firmen erlebt, die dachten, DNS-01 sei genauso trivial wie die HTTP-Validierung.
Die Illusion der sofortigen DNS-Verfügbarkeit
Der größte Fehler, den Techniker machen, ist der Glaube an eine synchrone Welt. Wenn ein Skript einen TXT-Record via API bei einem Provider wie Cloudflare, Hetzner oder AWS setzt, ist dieser Record zwar in der Datenbank des Providers vorhanden, aber noch lange nicht für die Validierungsserver von Let's Encrypt sichtbar. Wer blindlings darauf vertraut, dass die Meldung Let's Encrypt ACME: Preparing to Solve DNS-01 bedeutet, dass die Prüfung sofort starten kann, wird zwangsläufig gegen eine Wand fahren.
In der Praxis dauert es oft zwischen 60 und 300 Sekunden, bis ein Record global konsistent abrufbar ist. Viele billige DNS-Provider brauchen sogar bis zu zehn Minuten, um ihre Zonen-Updates auf alle Edge-Nameserver zu pushen. Ein erfahrener Praktiker weiß: Man prüft den Record selbst gegen die autoritativen Nameserver des Providers, bevor man dem ACME-Client das Signal gibt, fortzufahren. Wer das ignoriert, provoziert unnötige Fehlversuche, die das Konto bei der Zertifizierungsstelle für Stunden sperren können.
Warum das TTL-Missverständnis Zeit frisst
Oft höre ich das Argument, man habe doch die TTL (Time To Live) auf 60 Sekunden gesetzt. Das ist ein Denkfehler. Die TTL steuert, wie lange ein Resolver einen Wert zwischenspeichert. Sie hat absolut keinen Einfluss darauf, wie schnell die Infrastruktur Ihres Providers die neuen Daten intern verteilt. Wenn das System meldet, dass es bereit ist, den DNS-Check durchzuführen, bezieht sich das nur auf den lokalen Status des Clients. Es ist kein Versprechen, dass die Außenwelt bereit ist. Ich habe Systeme gesehen, bei denen ein simpler sleep 120 Befehl im Deployment-Skript mehr Probleme gelöst hat als jede komplexe API-Optimierung.
Let's Encrypt ACME: Preparing to Solve DNS-01 und das Berechtigungs-Chaos
Ein weiterer kritischer Punkt ist die Sicherheit der API-Tokens. Ich sehe ständig Setups, in denen ein einziger API-Key mit vollen Administrator-Rechten auf einem Webserver liegt, nur um ein Zertifikat zu erneuern. Das ist grob fahrlässig. Wenn dieser Server kompromittiert wird, hat der Angreifer die volle Kontrolle über die gesamte DNS-Zone der Firma. Er kann MX-Records ändern, E-Mails umleiten oder die gesamte Webseite auf eine Phishing-Präsenz spiegeln.
Die Lösung ist das Prinzip der minimalen Rechtevergabe. Ein API-Token für die DNS-Challenge sollte ausschließlich die Berechtigung haben, TXT-Records für die Subdomain _acme-challenge zu erstellen und zu löschen. Nichts anderes. Viele Provider erlauben mittlerweile dieses granulare Scoping. Wer das nicht nutzt, geht ein Risiko ein, das weit über ein abgelaufenes Zertifikat hinausgeht. Es geht hier um die Integrität der gesamten digitalen Identität des Unternehmens.
Der Irrweg über zentrale DNS-Server ohne API-Anbindung
Viele alteingesessene Firmen nutzen interne BIND-Server oder Windows DNS ohne moderne Schnittstellen. Wenn diese Leute versuchen, eine Wildcard-Validierung durchzuführen, enden sie oft bei manuellen Prozessen. Jemand kopiert einen Wert aus dem Terminal, loggt sich im Webinterface ein, fügt den TXT-Record ein und wartet. Das ist kein skalierbarer Prozess. Es ist eine Fehlerquelle par excellence. Einmal vertippt, eine Leerzeile zu viel, und der Prozess stirbt.
Die Lösung durch DNS-Delegierung via CNAME
Es gibt einen technischen Kniff, den viel zu wenige nutzen: die CNAME-Delegierung für die Challenge. Man erstellt für die Domain _acme-challenge.beispiel.de einen dauerhaften CNAME-Eintrag, der auf eine technisch flexiblere Zone zeigt, zum Beispiel auf einen dedizierten acme-dns-Server oder einen Provider mit einer schnellen API.
Hier ist der Vorher/Nachher-Vergleich: Früher musste der Admin alle drei Monate manuell in den veralteten DNS-Server der IT-Abteilung eingreifen, auf die Freigabe der Kollegen warten und hoffen, dass keine Tippfehler passieren. Der Prozess dauerte inklusive Kommunikation oft zwei Stunden pro Zertifikat. Heute ist ein permanenter CNAME gesetzt. Der ACME-Client kommuniziert vollautomatisch mit einem kleinen, abgesicherten DNS-Dienst, der nur für diesen Zweck existiert. Die Erneuerung passiert im Hintergrund in 90 Sekunden, ohne dass jemals wieder ein Mensch ein Interface anfassen muss. Das spart nicht nur Zeit, sondern schont auch die Nerven aller Beteiligten.
Lokale Resolver und das Problem der negativen Caches
Ein technisches Detail, das fast jeden mindestens einmal in den Wahnsinn treibt, ist der negative Cache. Angenommen, der ACME-Client schickt die Anfrage zur Validierung zu früh los. Der Validierungsserver von Let's Encrypt fragt den TXT-Record ab, findet ihn nicht und speichert das Ergebnis "Nicht vorhanden" für eine gewisse Zeit. Selbst wenn der Record eine Sekunde später erscheint, bleibt die Antwort für den Resolver oft noch für Minuten negativ.
In meiner Laufbahn habe ich gelernt, dass man dieses Risiko minimieren kann, indem man den Client so konfiguriert, dass er erst dann grünes Licht gibt, wenn mehrere externe DNS-Server (wie Google 8.8.8.8 oder Cloudflare 1.1.1.1) den korrekten Wert zurückgeben. Erst wenn die Mehrheit der Welt den Record sieht, ist die Phase Let's Encrypt ACME: Preparing to Solve DNS-01 wirklich abgeschlossen. Wer hier zu ungeduldig ist, zahlt mit Fehlermeldungen und Zeitverlust.
Das Risiko von Split-Horizon-DNS
In großen Unternehmensnetzwerken existiert oft ein sogenanntes Split-Horizon-DNS. Intern löst eine Domain zu einer privaten IP auf, extern zu einer öffentlichen. Wenn ein Skript nun versucht, die DNS-Challenge vorzubereiten, prüft es vielleicht gegen den internen DNS-Server. Dieser meldet Erfolg. Aber die Validierungsserver der Zertifizierungsstelle befinden sich im öffentlichen Internet und fragen die externen Nameserver ab. Wenn die Synchronisation zwischen intern und extern nicht perfekt ist, schlägt die Validierung fehl, obwohl lokal alles korrekt aussieht.
Dieses Problem ist besonders tückisch, weil es schwer zu debuggen ist. Man sitzt auf seinem Server, führt einen dig Befehl aus und sieht den korrekten TXT-Record. Man versteht die Welt nicht mehr, warum die Zertifizierungsstelle behauptet, da sei nichts. Der Fehler liegt darin, dass man aus der falschen Perspektive testet. Man muss immer aus der Perspektive des Prüfers denken, der von außen kommt. Ein guter Test-Workflow nutzt Werkzeuge, die DNS-Abfragen von verschiedenen globalen Standorten simulieren. Nur so stellt man sicher, dass die Vorbereitung auch wirklich gefruchtet hat.
Überfrachtung der DNS-Zone durch hängengebliebene Records
Ein sauberer Prozess löscht den TXT-Record nach erfolgreicher oder fehlgeschlagener Validierung sofort wieder. Ich habe Zonen gesehen, in denen hunderte alte _acme-challenge Einträge vor sich hin vegetierten. Das macht die Zone nicht nur unübersichtlich, sondern kann bei manchen Providern auch zu Performance-Problemen oder Limitierungen bei der Zonen-Größe führen. Zudem ist es unprofessionell.
Automatisierungsskripte müssen einen cleanup Schritt haben, der absolut zuverlässig ist. Ein Fehler im Skript darf nicht dazu führen, dass der Löschvorgang übersprungen wird. Ich nutze hierfür meistens trap Funktionen in Bash-Skripten oder finally Blöcke in moderneren Sprachen. Es ist wie beim Kochen: Wer die Küche nicht aufräumt, kann am nächsten Tag nicht vernünftig arbeiten. Ein sauberer DNS-Status ist die Basis für jede stabile Infrastruktur.
Realitätscheck für den Erfolg
Wer glaubt, dass DNS-01 die universelle Lösung für alle Probleme ist, irrt sich gewaltig. Dieser Weg ist komplexer, fehleranfälliger und langsamer als die einfache HTTP-Validierung. Er ist ein notwendiges Übel für Wildcard-Zertifikate oder für Server, die nicht über Port 80 erreichbar sind.
Um damit wirklich erfolgreich zu sein, braucht man drei Dinge:
- Einen DNS-Provider mit einer stabilen, dokumentierten und schnellen API.
- Ein Skript, das nicht nur blind Befehle abfeuert, sondern aktiv prüft, ob die Änderungen im öffentlichen DNS angekommen sind.
- Die Bereitschaft, Zeit in die Absicherung der Zugangsdaten zu investieren.
Es gibt keine magische Abkürzung. Wer die Wartezeiten ignoriert oder seine API-Keys ungeschützt lässt, wird früher oder später mit einem Ausfall bezahlen. DNS ist ein verteiltes System, und verteilte Systeme verzeihen keine Ungeduld. Erfolg bedeutet hier, dass man den Prozess so baut, dass er auch dann funktioniert, wenn das Netzwerk langsam ist oder ein API-Aufruf mal fehlschlägt. Wer das verinnerlicht hat, kann nachts ruhig schlafen, während die Zertifikate sich im Hintergrund geräuschlos erneuern. Es klappt nicht mit Glück, sondern nur mit sauberer Technik und Geduld. So funktioniert das Geschäft nun mal.
