dns-persist-01: Stand und Entscheidungsbaum für TLS-Zertifikate

⚡TL;DR

• dns-persist-01 bindet einen dauerhaften TXT-Eintrag an eine Zertifizierungsstelle und ein ACME-Konto. Die Verfügbarkeit hängt von beiden Seiten des Protokolls ab.
• Sie lassen den TXT-Eintrag bestehen. Die Zertifizierungsstelle darf sich nur 10 Tage auf eine Abfrage stützen: Danach liest sie denselben TXT-Eintrag erneut, bevor sie ein Zertifikat ausstellt.
• Am 16. September 2026 bleibt die Einführung bei Let's Encrypt eingefroren. Prüfen Sie zuerst Ihre Zertifizierungsstelle und dann Ihren Client, bevor Sie eine Erprobung erwägen.

Ein TXT-Eintrag, der veröffentlicht bleibt, kann die für die Domainvalidierung nötigen DNS-Schreibvorgänge reduzieren. Darin liegt der Nutzen von dns-persist-01 für Teams, die ihre TLS-Zertifikate häufiger verlängern müssen. Weder erneute Prüfungen durch die Zertifizierungsstelle (CA) noch die Installation des verlängerten Zertifikats entfallen dadurch.

Das Thema umfasst mehrere Ebenen: ein in den Baseline Requirements (BR) zugelassenes Verfahren, einen Entwurf für eine ACME-Challenge und Software mit unterschiedlichem Integrationsstand. Gehen Sie bei Ihrer Entscheidung von Ihrer tatsächlichen Ausstellungskette aus. Ein vorbereiteter Client macht seinen Server nicht kompatibel.

Wie ist der Stand von dns-persist-01 am 16. September 2026?

Stand am 16. September 2026

Die TLS BR v2.3.0 erlauben die persistente DNS-Validierung unter §3.2.2.4.22. Der Datatracker führt weiterhin draft-ietf-acme-dns-persist-01, ein Arbeitsdokument, dessen TXT-Syntax sich ändern kann.

Let's Encrypt hält die Einführung bis zur Klärung des weiterhin offenen IETF-ACME-Issues #64 eingefroren. Die Dokumentation nennt HTTP-01, DNS-01 und TLS-ALPN-01 als nutzbare Verfahren. Weder ein Produktionstermin noch der aktuelle Betrieb in der Staging-Umgebung werden hier bestätigt.

Der Grund für die Sperre ist ausdrücklich benannt. Am 25. Juni 2026 schrieb Aaron Gable: "We will not be deploying dns-persist-01 until [...] is resolved." Die ausgelassene Passage verweist auf Issue #64, das eine clientseitig berechnete Information im Nachweis fordert. Dieser Vorbehalt betrifft die Protokollsicherheit, nicht eine bloße Verzögerung bei der Paketierung. Aaron Gables Nachricht bleibt die maßgebliche Referenz für diesen Einführungsstopp.

Die Seite zu den Challenge-Typen von Let's Encrypt führt dns-persist-01 nicht unter den aktiven Verfahren auf. Sie enthält außerdem einen historischen Hinweis auf das eingestellte TLS-SNI-01. Das Ablaufdatum des Entwurfs -01 am 25. September 2026 betrifft diese Version des IETF-Dokuments. Es ist weder ein Starttermin noch eine Aufhebung der BR-Regelung.

Bei SwissSign hat sich die Quellenlage geändert. Der Beitrag vom 9. März 2026 kündigte einen Produktionsstart im Sommer an. Die aktuelle TLS-CP/CPS, Version 3.0 vom 24. August 2026, beschreibt Verfahren 22 inzwischen ausschließlich für Managed PKI. Ihr Änderungsverlauf datiert diese Ergänzung auf den 17. August. Das dokumentiert eine CA-Praxis in diesem Bereich; es beweist nicht, dass jeder ACME-Client dns-persist-01 mit diesem Dienst aushandeln kann.

Was dieser Artikel nicht abdeckt

Diese Bestandsaufnahme hilft Ihnen zu entscheiden, ob eine Erprobung für Ihren TLS-Bestand sinnvoll ist. Sie ersetzt weder den vollständigen Zeitplan für 47-Tage-Zertifikate noch den Leitfaden zur Automatisierung der TLS-Zertifikatsverlängerung. Diese Themen umfassen auch die Planung, Bereitstellung und Überwachung von Zertifikaten.

Dies ist auch kein Leitfaden zu CAA oder DNSSEC: Ihre Funktionen werden weiter unten mit Verweisen auf eigene Ressourcen voneinander abgegrenzt. Ebenso wenig ist es eine Anleitung zur Bereitstellung von dns-persist-01. Einen TXT-Eintrag zu veröffentlichen reicht nicht aus, damit eine CA die Challenge akzeptiert oder alle Verlängerungen erledigt sind.

Was validiert der persistente TXT-Eintrag und für wie lange?

Der TXT-Eintrag bildet eine an einen Aussteller und ein Konto gebundene Berechtigung zur Domainvalidierung ab. Die Dauer seiner Veröffentlichung unterscheidet sich von der Gültigkeitsdauer des Nachweises, den die CA erhält.

_validation-persist.[ADN]: DNS-Name, Aussteller und berechtigtes Konto

Das Verfahren steht in den BR §3.2.2.4.22, DNS-TXT-Eintrag mit persistentem Wert. ADN bedeutet Authorization Domain Name: der Domainname, mit dem die Berechtigung für den angefragten Namen eingeholt wird. Er bezeichnet nicht grundsätzlich die Stammdomain. Gehen Sie bei einem Dienst unter app.captaindns.com daher nicht davon aus, dass die CA zwangsläufig einen TXT-Eintrag unter captaindns.com abfragt.

Der abgefragte Name hat die Form _validation-persist.[ADN]. Sein Wert verwendet die Syntax issue-value aus RFC 8659, Abschnitt 4.2: issuer-domain-name; accounturi=KONTO_URI. Diese Schreibweise beschreibt die Felder; sie ist kein zu veröffentlichender Wert. issuer-domain-name identifiziert den Aussteller gemäß seiner CP/CPS, und accounturi bezeichnet das bei ihm berechtigte Konto. Ein CA-Name, der ihrem Markennamen ähnelt, ersetzt nicht die von ihr deklarierte Kennung.

Der optionale Parameter persistUntil ergänzt einen in Unix-Sekunden angegebenen Ablaufzeitpunkt. Danach kann der Eintrag nicht mehr für eine neue Validierung verwendet werden. Ohne diesen Parameter sieht die Syntax kein eigenes Ablaufdatum für den TXT-Eintrag vor. Da das ACME-Protokoll noch diskutiert wird, bewahren Sie die zu jeder Erprobung gehörende Spezifikationsversion auf.

Das Konto verdient ebenso viel Aufmerksamkeit wie das DNS. Wenn ein Dienstleister Ihre Organisation verlässt und seine URI in der Zone bleibt, besteht damit eine möglicherweise nicht mehr gewünschte Berechtigung fort. Planen Sie deren Entfernung, Cache-Fristen und den Umgang mit bereits erlangten Nachweisen ein. Das Löschen des TXT-Eintrags widerruft keine bereits ausgestellten Zertifikate.

Ein dauerhafter TXT-Eintrag, ein höchstens 10 Tage wiederverwendbarer CA-Nachweis

Die Wiederverwendung von Validierungsdaten ist bei diesem Verfahren auf höchstens 10 Tage begrenzt, sobald es eingesetzt wird. Diese Grenze gilt nicht erst 2029. Kann eine CA ihren Nachweis nicht mehr wiederverwenden, muss sie die Domain erneut validieren, bevor sie auf Grundlage dieses Verfahrens wieder ein Zertifikat ausstellt.

Vier Zeiträume bestehen nebeneinander: die Veröffentlichung des TXT-Eintrags, sein möglicher Ablaufzeitpunkt persistUntil, die Aktualität des CA-Nachweises und die Zertifikatsgültigkeit. Ein TXT-Eintrag, der ein Jahr lang veröffentlicht bleibt, kann mehreren aufeinanderfolgenden Prüfungen dienen. Daraus entsteht niemals eine einjährige Wiederverwendbarkeit des ersten Nachweises. Umgekehrt verpflichtet die Zehn-Tage-Grenze den Inhaber nicht dazu, den TXT-Eintrag alle zehn Tage zu ersetzen.

Das ist die angestrebte betriebliche Änderung: Die CA kann einen stabilen Eintrag erneut lesen, während der Client weiterhin Zertifikate anfordert und bereitstellt. Sie reduzieren validierungsbedingte Änderungen an der Zone, ohne die Verlängerungsarbeit abzuschaffen.

DV, OV, EV und Wildcard: welcher Geltungsbereich?

Bei DV-, OV- und EV-TLS-Zertifikaten betrifft dieses Verfahren die Validierung des Namens. Es prüft weder die Unternehmensidentität noch ersetzt es die für OV oder EV vorgeschriebenen Organisationsprüfungen. Ob ein Zertifikatstyp akzeptiert wird, entscheidet weiterhin die CA nach den Regeln des betreffenden Profils.

Die BR erlauben das persistente Verfahren zur Validierung von Wildcard-Namen, ohne die Einschränkungen der Zertifikatsprofile aufzuheben. Im ACME-Entwurf ist policy=wildcard optional, im normativen Sinne von MAY. Der technische Beitrag von Let's Encrypt beschreibt diese Erweiterung des Geltungsbereichs; er stellt kein verfügbares Angebot dar. Zum hier zugrunde gelegten Stand ist dns-persist-01 bei Let's Encrypt nicht nutzbar, auch nicht für Wildcards. Die herangezogene CP/CPS von SwissSign beschränkt die Wildcard-Validierung auf andere Verfahren.

Für IP-Adressen sieht §3.2.2.5.8 _ip-validation-persist unter dem entsprechenden Namen der Reverse-Zone vor; diese BR-Regelung belegt keine ACME-Verfügbarkeit.

S/MIME bleibt in den hier verglichenen Dokumenten unklar: Die Erwähnung im SwissSign-Beitrag erlaubt keinen Schluss auf eine Unterstützung der Challenge. Codesignierung und VMCs liegen außerhalb des Geltungsbereichs.

DNS-01, dns-account-01 und CAA: drei wesentliche Unterschiede

Diese Mechanismen erfüllen unterschiedliche Anforderungen, auch wenn sie DNS oder eine ACME-Kontokennung verwenden.

DNS-01 verwendet _acme-challenge, nicht den persistenten TXT-Eintrag

DNS-01 verlangt einen an die Challenge gebundenen Wert unter _acme-challenge. Der Eintrag trägt zu einem einmaligen Nachweis bei; er ist nicht die hier beschriebene persistente Berechtigung. Die Funktionsweise ist in RFC 8555, Abschnitt 8.4 definiert.

Bei dns-persist-01 ändern sich der abgefragte Name und der erwartete Inhalt. Ein altes DNS-01-Token in der Zone wird dadurch nicht zu einem persistenten TXT-Eintrag. Auch eine CNAME-Delegation von _acme-challenge bewirkt diese Umwandlung nicht. Für einen bereits automatisierten Bestand bleibt DNS-01 sinnvoll, solange die Kombination aus Client und CA es unterstützt.

dns-account-01 gehört zu einem anderen BR-Verfahren

dns-account-01 trennt die Validierungsnamen nach ACME-Konto. Das erleichtert insbesondere den gleichzeitigen Einsatz mehrerer Clients oder Dienstleister, ohne dass sie denselben Challenge-Namen teilen müssen. Der Wert bleibt an eine Validierung gebunden, anders als die dauerhafte Berechtigung von dns-persist-01.

Die BR verweisen unter §3.2.2.4.21 darauf, mit einem an Entwurf 00 gebundenen Ablauf. Der Datatracker des Projekts dns-account-label zeigt am Stichtag Version -03. Ein normativer Verweis in den BR, der Fortschritt bei der IETF und die Unterstützung durch eine CA sind drei verschiedene Informationen. Die bloße Bezeichnung als Entwurf würde die erste davon verdecken.

accounturi hat in CAA eine andere Funktion

CAA formuliert eine Ausstellungsrichtlinie: Es bestimmt, welche Zertifizierungsstellen ausstellen dürfen, und kann diese Erlaubnis auf ein Konto beschränken. Die Erweiterung accounturi ist in RFC 8657 definiert. Der gemeinsame Name mit dem Parameter des persistenten TXT-Eintrags macht daraus nicht denselben Nachweis.

Eine kompatible CAA-Richtlinie allein belegt keine Kontrolle über die Domain. Umgekehrt entbindet ein gültiger persistenter TXT-Eintrag die CA nicht von der CAA-Prüfung. Die Funktion von CAA-Einträgen ergänzt daher weiterhin das gewählte Validierungsverfahren.

Warum verändern 47-Tage-Zertifikate die Ausgangslage?

Häufigere Verlängerungen machen wiederholte DNS-Eingriffe aufwendiger, besonders wenn jede Änderung eine menschliche Freigabe verlangt.

2029: 47 Tage Zertifikatsgültigkeit und 10 Tage DCV-Wiederverwendung

Ab dem 15. März 2029 ist für öffentliche TLS-Zertifikate eine maximale Gültigkeit von 47 Tagen vorgesehen, bei zehn Tagen Wiederverwendbarkeit der Domainvalidierungsdaten. Der Zeitplan für TLS-Zertifikate mit 47 Tagen Laufzeit beschreibt die Zwischenschritte. Dieser allgemeine Zeitplan verschiebt nicht die bereits für das persistente Verfahren geltende Zehn-Tage-Grenze.

Der Nutzen hängt von Ihren Rahmenbedingungen ab. Ein Team, dessen DNS manuelle Änderungen erfordert, kann wiederkehrende Eingriffe vermeiden, wenn seine CA eine dauerhafte Berechtigung akzeptiert. Ein Team, bei dem DNS-01 bereits mit eingeschränkten Rechten funktioniert, muss anders abwägen. In beiden Fällen muss das Zertifikat weiterhin vor seinem Ablauf beim richtigen Dienst ankommen.

CNAME-Delegation und acme-dns: was die BR empfehlen

BR §3.2.2.4.7 betreffen ausdrücklich den Fall, dass eine CA oder eine verbundene Organisation eine Zone betreibt, die CNAME-Delegationen zur Validierung empfängt. Dieser Dienst ähnelt dem acme-dns-Modell. Der Text verwendet SHOULD NOT für den Betrieb und SHOULD für die Empfehlung an Nutzer, §3.2.2.4.22 zu verwenden. Die Ergänzung stammt aus Abstimmungsvorlage SC-088v3.

Das sind starke normative Empfehlungen, kein absolutes Verbot jeglicher CNAME-Delegation. Sie richten sich an die CA oder die mit ihr verbundene Organisation, die den Dienst betreibt. Daraus folgt keine Aufforderung, Ihre acme-dns-Instanz sofort zu löschen, und erst recht nicht, zu einer bei Let's Encrypt nicht verfügbaren Challenge zu wechseln. Fragen Sie nach, welches Verfahren Ihre Zertifizierungsstelle akzeptiert, bevor Sie einen funktionierenden Aufbau ändern.

ACME-Clients: welche Belege für Unterstützung gibt es am 16. September 2026?

Die verfügbaren Belege reichen von einer veröffentlichten Version bis zu einer offenen Funktionsanfrage. Die folgende Matrix beschreibt diesen am 16. September 2026 geprüften Dokumentationsstand; sie ordnet keine zur Ausstellung fähigen Zertifizierungsstellen ein.

Client	Version oder Änderungsstand	Genaue Primärquelle	Stichtag	Geltungsbereich und Grenzen auf CA-Seite
lego	Implementierung ab v5.0.0 vorhanden, mit Anpassung an Entwurf -01	Version v5.0.0, insbesondere Änderung #2991	16.09.2026	Beleg für lego ≥ v5.0.0; Kompatibilität der gewählten Version mit der CA prüfen. Keine LE-Verfügbarkeit daraus abgeleitet.
acme.sh	Version 3.1.4 kündigt dns-persist-01 an; Modus dokumentiert	Version 3.1.4 und Wiki zum persistenten DNS-Modus	16.09.2026	Belegte Version, ohne Anspruch auf Feststellung der ersten kompatiblen Version. Die Wiki-Beispiele beweisen keine aktuelle LE-Verfügbarkeit.
Certbot	PR #10633 am 3. August 2026 geschlossen, nicht zusammengeführt; Anfrage #10549 offen	PR #10633 und Issue #10549	16.09.2026	Die Änderung am manuellen Modul wird durch diese PR nicht ausgeliefert. Aus ihrem früheren Meilenstein wird kein nutzbarer Ablauf abgeleitet.
cert-manager	Anfrage #8373 offen	Issue #8373	16.09.2026	Eine Anfrage belegt weder eine veröffentlichte Implementierung noch die Kompatibilität mit einer CA.
win-acme	Anfrage #2849 offen	Issue #2849	16.09.2026	Das im Issue-Titel genannte Quartal ist kein Liefertermin. Die Akzeptanz durch die CA ist gesondert zu prüfen.

Für lego liefert v5.0.0 bereits einen veröffentlichten Beleg: Die Einführung der Challenge einer späteren Version zuzuschreiben wäre irreführend. Bei Certbot bedeutet der geschlossene Zustand der PR nicht, dass sie zusammengeführt wurde; die GitHub-API bestätigt merged: false. Diese Unterschiede verändern die betriebliche Entscheidung.

Bewahren Sie die Versionsreferenzen in Ihren Erprobungsunterlagen auf. Ein von einer Distribution bereitgestelltes oder in ein anderes Produkt eingebettetes Paket kann von der neuesten Version des Ursprungsprojekts abweichen. Prüfen Sie anschließend das von der CA tatsächlich angebotene Verfahren für die betreffende Berechtigung. Eine vorhandene Client-Option ersetzt diese Prüfung nicht.

DNSSEC und MPIC: warum die Validierung trotz vorhandenem TXT-Eintrag scheitern kann

Eine von Ihrem Arbeitsplatz aus lesbare TXT-Antwort belegt weder ihre DNSSEC-Gültigkeit noch ihre Sichtbarkeit aus den Perspektiven der CA.

SC-085 betrifft auch die persistente DNS-Validierung

SC-085 verlangt die DNSSEC-Validierung von DCV-Abfragen durch die Hauptperspektive der CA. Das persistente Verfahren ist davon nicht ausgenommen. BR v2.3.0 bündeln diese Anforderungen unter §4.2.2.2. Eine ungültige signierte Kette kann daher eine Validierung blockieren, obwohl der TXT-Text korrekt ist.

Das macht die DNSSEC-Signierung nicht für alle Domains verpflichtend. Eine unsignierte Zone ist von einer Zone mit defekter Vertrauenskette zu unterscheiden. Ein Wechsel des DNS-Anbieters bei weiterhin veröffentlichtem altem DS kann den zweiten Fall verursachen. Unser Artikel zur DNSSEC-Validierung von TLS-Zertifikaten und SC-085 erklärt diese Diagnose.

Geografisch unterschiedliche DNS-Antworten können MPIC scheitern lassen

MPIC, Multi-Perspective Issuance Corroboration, gleicht die Beobachtungen mehrerer Netzwerkperspektiven ab. Beim persistenten Verfahren müssen die bestätigenden Perspektiven einen gültigen Nachweis mit demselben accounturi wie die Hauptperspektive sehen. Der Mechanismus folgt den Quorumregeln der BR, nicht einer einfachen lokalen DNS-Abfrage.

Geografisch variierende DNS-Antworten können zum Scheitern führen, wenn manche Perspektiven ein anderes Konto erhalten oder keinen nutzbaren Nachweis finden. Das schließt nicht jedes GeoDNS aus: Je nach Region unterschiedliche A-Antworten können mit einem konsistenten Validierungs-TXT-Eintrag zusammen bestehen. Entscheidend sind die zur Validierung verwendete Antwort und die erforderlichen Perspektiven, nicht die Produktbezeichnung des DNS-Dienstes.

Entscheidungsbaum: abwarten, erproben oder das bisherige Verfahren beibehalten?

Beginnen Sie bei der Zertifizierungsstelle, prüfen Sie dann den Client und Ihre Fähigkeit, die Berechtigung zu verwalten. Jede Antwort muss auf einem datierten Beleg beruhen.

Akzeptiert Ihre Zertifizierungsstelle das Verfahren für das vorgesehene Zertifikat?

Suchen Sie nach einer in der CP/CPS deklarierten Praxis und einer zu Ihrem Vertrag passenden Dienstdokumentation. Die Erwähnung von Managed PKI bedeutet keinen Zugang für alle Konten oder Profile. Prüfen Sie auch den Wildcard-Fall, falls Sie darauf angewiesen sind.

Lautet die Antwort nein oder ist sie unklar, behalten Sie ein unterstütztes Verfahren bei. Für Let's Encrypt ist beim beschriebenen Stand Abwarten die Entscheidung. Eine alte Ankündigung oder eine Bildschirmaufnahme aus der Staging-Umgebung reicht nicht aus, um eine Produktionsumstellung zu planen.

Hat Ihr Client eine veröffentlichte und kompatible Implementierung?

Gleichen Sie die installierte Version mit der Matrix und anschließend mit der von der CA akzeptierten Spezifikation ab. Eine nicht zusammengeführte PR oder eine offene Anfrage liefert für diesen Schritt keinen Nachweis einer Auslieferung. Warten Sie je nach Situation ab oder bereiten Sie eine Erprobung außerhalb der Produktion mit den tatsächlich verfügbaren Komponenten vor.

Dokumentieren Sie das erwartete Ergebnis: Aushandlung der Challenge, Validierung, Ausstellung und anschließend Verlängerung. Ein erstes ausgestelltes Zertifikat allein beweist nicht, dass die Verlängerung nach Ablauf des CA-Nachweises funktioniert.

Sind Ihr DNS und Ihre Berechtigungsverwaltung vorbereitet?

Klären Sie, wer den TXT-Eintrag kontrolliert, wem das berechtigte Konto gehört und wer die Berechtigung entfernen kann. Prüfen Sie DNSSEC und die Sichtbarkeit des Namens aus mehreren Netzen. Berücksichtigen Sie auch das Ausscheiden eines Dienstleisters oder den Austausch eines Kontos.

Sind alle Bedingungen dokumentiert, ist eine kontrollierte Erprobung bei der betreffenden CA sinnvoll. Behalten Sie die Überwachung der Verlängerungen und ein erprobtes Wiederherstellungsverfahren bei. Der erwartete Gewinn besteht in weniger DNS-Schreibvorgängen; er lässt sich messen, ohne davon auszugehen, dass künftig jeder Eingriff entfällt.

TXT-Eintrag und DNSSEC prüfen, ohne die Akzeptanz durch die CA vorauszusetzen

Die TXT-Abfrage hilft, den tatsächlich betroffenen Namen unter _validation-persist zu beobachten. Die DNSSEC-Prüfung untersucht die Vertrauenskette der Domain. Diese beiden Prüfungen unterstützen die DNS-Diagnose; sie handeln weder die Challenge mit Ihrer Zertifizierungsstelle aus noch garantieren sie die Ausstellung eines Zertifikats.

DNS watch kann diese Arbeit durch eine kostenlose, verfahrensübergreifende Überwachung von DNS-Änderungen ergänzen. Eine Warnung hilft, eine Entfernung oder Änderung zu erkennen; sie bestätigt keine ACME-Kompatibilität. Maßgeblich bleibt das dokumentierte Verhalten der Kombination aus Client und CA für das angeforderte Zertifikat.

FAQ

Ersetzt dns-persist-01 DNS-01 und dns-account-01?

Nein. Es bietet eine dauerhafte DNS-Berechtigung, die an ein Konto und einen Aussteller gebunden ist. DNS-01 und dns-account-01 verwenden andere Nachweise und bleiben je nach Unterstützung eigenständige Optionen.

Ist dns-persist-01 bei Let's Encrypt am 16. September 2026 nutzbar?

Die Einführung bleibt bis zur Klärung des IETF-Issues #64 eingefroren. Die Dokumentation der aktiven Challenges bietet das Verfahren nicht an. Weder eine Produktions- noch eine Staging-Verfügbarkeit wird hier belegt.

Warum die Domain erneut validieren, wenn der TXT-Eintrag veröffentlicht bleibt?

Die Zertifizierungsstelle darf sich höchstens 10 Tage auf eine DNS-Abfrage stützen. Danach liest sie denselben TXT-Eintrag erneut, bevor sie ein Zertifikat ausstellt; Sie müssen ihn nicht ersetzen.

Deckt dns-persist-01 DV-, OV-, EV- und Wildcard-Zertifikate ab?

Die persistente Validierung betrifft bei DV, OV und EV den Namen, ohne die Unternehmensprüfungen zu ersetzen. Die BR erlauben die Wildcard-Validierung mit diesem Verfahren, vorbehaltlich der Profilregeln und der Akzeptanz durch die CA. Let's Encrypt bietet es zum erfassten Stand nicht an.

Reicht ein kompatibler ACME-Client für dns-persist-01 aus?

Nein. Die CA muss das Verfahren für Ihr Konto und Ihr Zertifikat akzeptieren. Eine Client-Version belegt eine Implementierung, nicht die Verfügbarkeit des entfernten Dienstes.

Garantiert ein bei einer Abfrage sichtbarer TXT-Eintrag eine erfolgreiche DNSSEC- und MPIC-Validierung?

Nein. Das Ergebnis hängt vom Resolver und vom Beobachtungspunkt ab. Die CA muss weiterhin DNSSEC validieren und die erforderliche Bestätigung aus ihren Netzwerkperspektiven erhalten.