DNS-PERSIST-01: Ein neues Modell für die DNS-basierte Challenge-Validierung

• DNS-PERSIST-01 von Let's Encrypt ist ein neues ACME-Challenge-Modell, das die wiederholte Validierung des bisherigen DNS-01-Verfahrens ersetzt und dauerhafte Autorisierungs-Records verwendet
• Dieses Verfahren weist die Kontrolle über eine Domain langfristig über einen an ein bestimmtes ACME-Konto und eine CA gebundenen TXT-Record nach
• Es reduziert DNS-Änderungen und den Aufwand für die Verteilung von API-Zugangsdaten und stärkt damit zugleich Betriebseffizienz und Sicherheit
• Es unterstützt feingranulare Steuerungsfunktionen wie Policy-Optionen (policy=wildcard), Ablaufzeitpunkt (persistUntil) und die Zulassung mehrerer CAs
• Das Staging ist für Ende des 1. Quartals 2026 geplant, der breite Rollout für das 2. Quartal; erwartet wird eine vereinfachte Zertifikatsverwaltung in großskaligen und automatisierten Umgebungen

---

Grenzen des DNS-01-Verfahrens

• Die bisherige DNS-01-Challenge erzeugt bei jeder Zertifikatsausstellung ein neues Token und erfordert das Hinzufügen eines TXT-Records unter _acme-challenge.
  • Für jede Validierung ist ein DNS-Update nötig, was zu Ausbreitungsverzögerungen und komplexerer Automatisierung führt
• In großen Deployments werden DNS-API-Zugangsdaten auf mehrere Systeme verteilt, was das Sicherheitsrisiko erhöht
• Einige Nutzer möchten solche wiederholten DNS-Änderungen vermeiden

Aufbau und Funktionsweise von DNS-PERSIST-01

• Das neue Verfahren führt das Konzept einer dauerhaften Autorisierung (persistent authorization) ein
  • Unter _validation-persist. wird einmalig ein TXT-Record eingerichtet, der die URI der CA und des ACME-Kontos enthält
  • Danach kann derselbe Record für Ausstellung und Erneuerung wiederverwendet werden
• Beispiel:

  _validation-persist.example.com. IN TXT (  
    "letsencrypt.org;"  
    " accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"  
  )  
  

• Dadurch werden DNS-Änderungen aus dem Ausstellungspfad entfernt, was die Betriebseffizienz verbessert

Ausgewogenheit zwischen Sicherheit und Betrieb

• Während bei DNS-01 DNS-Schreibrechte das zentrale Gut waren, ist bei DNS-PERSIST-01 der Schutz des ACME-Kontoschlüssels entscheidend
• Nach der Ersteinrichtung kann der DNS-Schreibzugriff eingeschränkt werden, was die Angriffsfläche reduziert
• Wegen der Struktur mit dauerhafter Autorisierung steigt jedoch das Risiko bei einem Verlust des Kontoschlüssels, daher ist ein verstärktes Account-Sicherheitsmanagement nötig

Steuerung von Geltungsbereich und Lebensdauer

• Standardmäßig ist die Validierung nur für den verifizierten FQDN unbegrenzt gültig
• Mit der Option policy=wildcard kann sie auf Wildcard- und Subdomains ausgeweitet werden

  "policy=wildcard"  
  

• Mit dem Attribut persistUntil kann ein Ablaufzeitpunkt (UTC in Sekunden) festgelegt werden
  • Eine Verlängerung vor Ablauf ist erforderlich, ein Monitoring-System ist daher unverzichtbar

  "persistUntil=1767225600"  
  

• Wenn mehrere CAs gleichzeitig erlaubt sein sollen, müssen unter _validation-persist. CA-spezifische TXT-Records hinzugefügt werden

Einführungszeitplan und Implementierungsstand

• Die Abstimmung zu CA/Browser Forum SC-088v3 wurde im Oktober 2025 einstimmig angenommen, die IETF-ACME-Arbeitsgruppe hat den Entwurf übernommen
• Unterstützung besteht bereits in Pebble (einer verkleinerten Version von Boulder), und auch eine Client-Implementierung für lego-cli ist in Arbeit
• Staging Ende des 1. Quartals 2026, breite Bereitstellung im 2. Quartal geplant
• Das Modell eignet sich besonders für Bereiche, in denen das bisherige Verfahren ineffizient ist, etwa IoT-, Multi-Tenant- und Umgebungen mit hohem Zertifikatsausstellungsvolumen

Hintergrund zu Let's Encrypt und ISRG

• Let's Encrypt ist eine von der gemeinnützigen Organisation ISRG betriebene kostenlose, automatisierte und offene Zertifizierungsstelle (CA)
• Im Jahresbericht 2025 veröffentlichte die ISRG ihre Aktivitäten rund um Internetsicherheit

[GN⁺]

Hacker-News-Kommentare

• Ich freue mich wirklich sehr, diese Nachricht zu sehen
  Wenn ich bind als autoritativen Nameserver nutze, richte ich es so ein, dass die hmac-secret-Berechtigung so eingeschränkt ist, dass jeder Webserver nur die zugehörigen TXT-Records aktualisieren kann
  So kann selbst dann, wenn der Server „bob“ kompromittiert wird, nur ein Zertifikat für die Domain „bob“ ausgestellt werden
  Ein Beispiel für die Konfiguration ist, mit update-policy jeden Schlüssel darauf zu beschränken, nur Subdomains unter _acme-challenge zu ändern

  • Wenn man bereit ist, statt bind einen separaten DNS-Server zu betreiben, bietet acmedns eine ähnliche Funktion
    Beim Anlegen eines neuen Kontos wird eine eindeutige Subdomain vergeben, und wenn man die Challenge-Domain per CNAME auf diese Subdomain zeigt, kann nur dieses Konto diesen Bereich aktualisieren

• Ich denke, diese Funktion löst ein tatsächlich großes praktisches Ärgernis
  Allerdings mache ich mir Sorgen über die Offenlegung von Identifikatoren für Administratorkonten
  Benutzernamen werden nicht so gut geschützt wie Zugangsdaten, können Angreifern aber Hinweise auf lohnende Ziele geben
  Es ist gut möglich, dass Dienste wie Shodan solche IDs indexieren und Rückwärtssuchen anbieten

  • Auch der accounturi in CAA-Records legt bereits Konto-Identifikatoren offen, also ist das in gewissem Maß ohnehin schon öffentlich
    Ich denke eher, dass es besser ist, wenn CAA und das Persist-Record-Format übereinstimmen
  • Es wäre gut, Nutzern statt des tatsächlichen Kontos eine zufällige ID wie eine UUID zu geben, die dann in accounturi verwendet wird
  • Da es sich um dasselbe Konto handelt, das auch der ACME-Client erstellt, halte ich das Risiko einer Rückwärtssuche nicht für besonders groß

• Ich bin überrascht, dass DNSSEC nicht vorausgesetzt wird
  Früher hielt ich DNSSEC für umständlich, aber inzwischen gibt es mit CAA, CERT, SSHFP, TXT und anderen Records, die die Root of Trust beeinflussen, viele Angriffspunkte für MITM-Attacken
  Gerade weil selbst große Unternehmen DNSSEC oft nicht korrekt einsetzen, sollte es meiner Meinung nach zumindest als Empfehlung ausdrücklich genannt werden

  • Auch im RFC-Entwurf wird der Einsatz von DNSSEC als „SHOULD“ empfohlen (Link)
  • DNS war schon immer ein Single Point of Failure bei der Ausstellung von TLS-Zertifikaten
    Wenn ein Angreifer DNS kontrolliert, kann er über HTTP-01, TLS-ALPN-01 oder DNS-01 gleichermaßen Zertifikate fälschen
  • Persönlich halte ich TLSA für den besseren Ansatz als DNSSEC, schade nur, dass Browser es kaum unterstützen

• Dank dieser Funktion dürfte es viel einfacher werden, Zertifikate für LAN-Server auszustellen, die nicht dem Internet ausgesetzt sind
  Künftig werden wohl die meisten Admin-UIs automatisch den in DNS einzutragenden String erzeugen und direkt ein Let's-Encrypt-Zertifikat beziehen können

  • Ich habe etwas Ähnliches in einer vergleichbaren Umgebung ausprobiert, aber die Einrichtung von headscale magic DNS war komplizierter als gedacht, sodass ich am Ende wieder auf manuelle Erneuerung zurückgegangen bin

• Wer certbot nutzt, kann den Stand der Unterstützung dieser Funktion im GitHub-Issue verfolgen

• Früher war ich bei kurzlebigen Zertifikaten skeptisch, aber durch IP-Adress-Zertifikate und die HTTP-01-Verifikation habe ich meine Meinung geändert
  Inzwischen speichere ich Zertifikate nicht mehr auf der Festplatte, sondern ein Background-Thread prüft alle 24 Stunden auf ein neues Zertifikat
  So lässt sich eine Self-Hosting-Lösung bauen, bei der Nutzer Software auf einer VM bereitstellen und innerhalb von 5 Minuten produktiv sein können
  In Kombination mit Diensten wie checkip.amazonaws.com sind vollständig automatisierte Deployments möglich

  • Die Ausstellungslimits von Let's Encrypt sind allerdings nicht verhandelbar; wenn man zu oft anfragt, riskiert man Wartezeiten
  • Wenn man Zertifikate überhaupt nicht speichert, hängt die Verfügbarkeit von der Uptime von LE ab, daher ist ein Mindestmaß an Speicherung nötig

• Endlich scheint es einfacher automatisierbar zu werden, Zertifikate für rein interne Webservices zu nutzen
  Es fühlt sich an, als würde damit das bisher größte operative Problem gelöst, was mich sehr freut

• Was hier fehlt, ist die Verifikation des Besitzes des ACME-Kontos
  Die meisten Automatisierungswerkzeuge erstellen das Konto zwar selbst, sodass Nutzer es nicht direkt anfassen, aber jetzt müssen Anmeldedaten zum Nachweis des Kontobesitzes an den ACME-Anbieter übermittelt werden
  Wenn Let's Encrypt keine auf einzelne Domains begrenzten Tokens erstellen kann, muss man möglicherweise für jede Domain ein separates Konto anlegen

  • ACME-Konten besitzen jedoch bereits Authentifizierungsdaten, und der Domainbesitz wird über DNS- oder HTTP-Challenges verifiziert
    Falls diese Zugangsdaten oder Endpunkte kompromittiert werden, ist ohnehin schon ein deutlich größeres Problem entstanden

• Für Nutzer von Dynamic DNS ist das wirklich eine sehr willkommene Nachricht
  Wenn Änderungen zum Beispiel wie bei Namecheap nur von einer festen IP aus möglich sind, kann man nach einmaliger Einrichtung jetzt automatische Erneuerungen nutzen
  Bei der Modernisierung meines Homelabs werde ich das auf jeden Fall ausprobieren

• Wenn ich das nicht falsch verstehe, frage ich mich, ob dann nicht jemand, der die DNS-Server meiner Domain kontrolliert, oder jemand, der den Traffic zwischen Let's Encrypt und den DNS-Servern abfängt, ein TLS-Zertifikat für meine Domain ausstellen lassen kann
  Das gilt zwar auch für DNS-01, aber bei diesem Verfahren wirkt es noch einfacher, weil der Angreifer nur sein eigenes LE-Konto in die DNS-Antwort eintragen müsste
  Wäre es nicht besser, stattdessen mein öffentliches Zertifikat direkt in DNS einzutragen?

  • Wenn man dem DNS-Anbieter nicht vertrauen kann, ist schon diese Beziehung selbst das Problem
    Wenn jemand den Traffic zwischen LE und den DNS-Servern per MITM manipulieren kann, ist die Lage ohnehin bereits deutlich ernster
  • Wer DNS kontrolliert, kann sich bei jeder beliebigen CA Zertifikate ausstellen lassen
    Wenn jemand DNS ändern kann, gibt es keine Möglichkeit, die Zertifikatsausstellung zu verhindern
  • Wer DNS kontrolliert, kann auch HTTP-Challenges bestehen; praktisch gehört ihm die Domain damit bereits
  • CAs fragen DNS von mehreren Standorten aus ab, um solche Netzwerkangriffe abzumildern
    Let's Encrypt arbeitet bereits seit Jahren so, und seit 2024 ist das für alle CAs verpflichtend
    Link zu den CAB-Forum-Regeln
  • So einen Ansatz verfolgt im Grunde auch DANE
    Weiterführendes Material