Toggle search modal

ACME über RFC 2136: DNS-01-Validierung mit TSIG-Authentifizierung erklärt

RFC 2136 ist der IETF-Standard für dynamische DNS-Updates mit kryptografisch authentifizierter Kommunikation. In Verbindung mit dem ACME-Protokoll wird RFC 2136 zum bevorzugten Weg für die DNS-01-Validierung – besonders bei Wildcard-Zertifikaten, in Enterprise-Umgebungen und überall dort, wo Vendor-Lock-in vermieden werden soll. Diese Seite erklärt die technischen Grundlagen, das DCV-Zonen-Konzept als Sicherheits-Architektur sowie den Weg, wie LEMARIT die RFC-2136-Schnittstelle nativ und CA-neutral anbietet.

Sie wollen die praktische Umsetzung sehen?

Werfen Sie einen Blick auf unsere Schritt-für-Schritt-Anleitung

ACME mit DNS-01 einrichten
Inhalte

Was ist RFC 2136 – und warum ist es für ACME relevant?

RFC 2136 ist eine Erweiterung des DNS-Protokolls, die es erlaubt, DNS-Einträge nicht statisch über Konfigurationsdateien, sondern dynamisch zur Laufzeit zu setzen, zu ändern oder zu löschen. Die 1997 verabschiedete Spezifikation definiert das Nachrichtenformat und den Ablauf dafür – auf Betriebssystem-Ebene meist über das Kommandozeilen-Tool 
nsupdate
implementiert.
Für den DNS-Betrieb ist RFC 2136 ein Sicherheitsrisiko, wenn es nicht durch eine kryptografische Authentifizierung abgesichert wird. Deshalb wird RFC 2136 in der Praxis immer in Kombination mit TSIG (Transaction Signature, RFC 2845) eingesetzt: Ein geteilter symmetrischer Schlüssel signiert jede Update-Anfrage, sodass der DNS-Server verifizieren kann, dass die Anfrage von einer autorisierten Quelle stammt.
Für die ACME-DNS-01-Validierung ist RFC 2136 aus drei Gründen besonders wertvoll.

Erstens: Standardisierung. Anders als bei DNS-Provider-spezifischen APIs (z. B. Cloudflare-API, Route-53-Plugin, DigitalOcean-Plugin) ist RFC 2136 herstellerneutral. Jeder DNS-Server, der den Standard implementiert, kann angesprochen werden – ohne dass der ACME-Client anbieter-spezifisch konfiguriert werden muss.

Zweitens: Native Unterstützung in ACME-Clients. Die drei etablierten Clients – Certbot, acme.sh und cert-manager – unterstützen RFC 2136 nativ. Certbot bringt das Plug-in 
certbot-dns-rfc2136
mit, acme.sh nutzt den 
nsupdate
-Hook, cert-manager hat einen eingebauten 
rfc2136
-Solver. In allen drei Fällen ist die Anbindung deutlich schlanker als eine Custom-Anbindung an eine proprietäre DNS-API.

Dritter Punkt: Rechte-Trennung. Ein TSIG-Key kann architektonisch so ausgestellt werden, dass er nur auf ein einziges Subdomain-Segment schreiben darf – nicht auf die gesamte DNS-Zone. Damit ist das Schaden-Potenzial bei kompromittiertem Key strukturell begrenzt.

Der Ablauf einer ACME-DNS-01-Validierung über RFC 2136

Der komplette Prozess lässt sich in fünf Schritten beschreiben.
Schritt 1 – Client stellt Zertifikats-Anfrage. Der ACME-Client (Certbot, acme.sh oder cert-manager) sendet eine Order-Anfrage an die Certificate Authority. In der Order sind ein oder mehrere Domain-Namen enthalten, für die ein Zertifikat ausgestellt werden soll – gerne auch Wildcard-Muster wie 
*.example.com
.
Schritt 2 – CA gibt Challenge zurück. Die CA antwortet mit einer DNS-01-Challenge: Der Client muss einen TXT-Eintrag mit einem spezifischen Token unter 
_acme-challenge.< domain>
im DNS setzen. Bei Wildcards ist das der einzig gangbare Validierungs-Weg – HTTP-01 und TLS-ALPN-01 funktionieren nicht für Wildcards.

Schritt 3 – Client setzt TXT-Eintrag per RFC 2136. Der Client baut eine nsupdate-Anfrage zusammen, signiert sie mit dem hinterlegten TSIG-Key und schickt sie an den konfigurierten DNS-Server. Der DNS-Server verifiziert die Signatur, führt das Update aus und propagiert den neuen TXT-Eintrag.

Schritt 4 – CA validiert. Die CA fragt den TXT-Eintrag über die öffentliche DNS-Auflösung ab, prüft den Token-Wert und markiert die Challenge als erfolgreich.

Schritt 5 – CA stellt Zertifikat aus. Nach erfolgreicher Validierung signiert die CA den Certificate Signing Request des Clients und stellt das Zertifikat zusammen mit der Chain zur Verfügung. Der Client räumt in der Regel automatisch den TXT-Eintrag wieder auf.

Der komplette Zyklus dauert bei sauberer Konfiguration typischerweise 10 bis 30 Sekunden. Bei manuellen DNS-Provider-Setups mit langsamer TTL-Propagation können es dagegen mehrere Minuten sein – der Geschwindigkeitsvorteil ist bei RFC 2136 erheblich.

Warum RFC 2136 der bessere Weg für DNS-01 ist

Wer heute ACME-basierte SSL-Automation für Wildcard-Zertifikate oder interne Hosts umsetzt, hat drei realistische DNS-01-Optionen: RFC 2136, ein DNS-Provider-spezifisches Plug-in oder eine Custom-API-Integration. Der Vergleich fällt in mehreren Dimensionen zugunsten von RFC 2136 aus.

Herstellerneutralität. Ein DNS-Provider-Plug-in bindet Sie an genau einen Anbieter. Wenn Sie den DNS-Provider wechseln, müssen Sie den ACME-Client neu konfigurieren. Bei RFC 2136 ist der Wechsel deutlich weniger schmerzhaft – jeder RFC-2136-fähige DNS-Server (BIND, PowerDNS, LEMARIT und andere) kann direkt angesprochen werden.

Sicherheitsmodell. Provider-Plug-ins arbeiten oft mit API-Tokens, die auf die gesamte DNS-Zone Schreibrechte haben. Bei Kompromittierung eines solchen Tokens kann ein Angreifer nicht nur Validierungs-Einträge manipulieren, sondern auch DNSSEC-Signaturen, MX-Records, SPF- und DKIM-Einträge. Ein TSIG-Key hingegen lässt sich auf einen einzigen Subdomain-Namespace beschränken – die Angriffsfläche ist strukturell kleiner.

Wartungsaufwand. Provider-Plug-ins folgen unterschiedlichen Release-Zyklen und werden je nach ACME-Client mal besser, mal schlechter gepflegt. RFC 2136 ist ein stabiler IETF-Standard – die Client-Implementierungen ändern sich nur, wenn der Standard selbst weiterentwickelt wird. In Enterprise-Umgebungen mit langen Betriebs-Horizonten ist das ein handfester Vorteil.

Enterprise-Compliance. Interne Audits, ISO-27001-Prüfungen und BSI-Grundschutz-Anforderungen verlangen zunehmend eine dokumentierte Rechte-Trennung bei DNS-Update-Pfaden. Mit RFC 2136 und einem eng gescopten TSIG-Key lässt sich dieser Nachweis strukturell erbringen – bei API-Token-Modellen ist das deutlich mühsamer.

DCV-Zonen-Konzept – die Sicherheits-Architektur hinter RFC 2136

Auch ein sauber implementiertes RFC-2136-Setup hat eine Schwachstelle, wenn der TSIG-Key auf die produktive DNS-Zone schreibt. Bei einem kompromittierten Server könnte ein Angreifer im schlimmsten Fall genau denselben Schaden anrichten wie mit einem gestohlenen API-Token. Die architektonische Antwort auf dieses Problem heißt CNAME-Delegation, in der Praxis oft als DCV-Zonen-Konzept bezeichnet.

Wie CNAME-Delegation funktioniert

Statt dem ACME-Client Schreibrechte auf 
example.com
zu geben, wird der 
_acme-challenge
-Subnamespace per CNAME auf eine dedizierte Validierungs-Zone umgeleitet. Konkret: 
				
					_acme-challenge.example.com.  CNAME  _acme-challenge.example.dcv.lemarit.cloud.
Der TSIG-Key des ACME-Clients hat dann Schreibrechte ausschließlich auf die Validierungs-Zone ( 
example.dcv.lemarit.cloud
). Die produktive Zone 
example.com
bleibt für den Client strukturell unerreichbar.

Warum dieses Konzept wichtig ist

Erstens: Kein Angriffsvektor auf die Produktivzone. Selbst wenn der TSIG-Key kompromittiert wird, kann ein Angreifer nichts an DNSSEC-Signaturen, MX-Records, SPF, DKIM oder anderen produktiven Einträgen manipulieren. Er kann höchstens Validierungs-Einträge in der DCV-Zone setzen – was für sich genommen keinen Schaden verursacht, weil die Zertifikats-Ausstellung eine separate Autorisierung braucht.

Zweitens: Compliance-Konformität. Das BSI weist im IT-Grundschutz-Kompendium explizit auf die Risiken unzureichend abgesicherter DNS-Update-Pfade hin. In stark regulierten Branchen wie Banken, Versicherungen oder KRITIS-Betreibern wird die DCV-Trennung zunehmend in Audits nachgefragt.

Dritter Punkt: Skalierbarkeit für Multi-Domain-Portfolios. Das DCV-Zonen-Konzept skaliert sauber, wenn ein Unternehmen viele Domains verwaltet. Für jede Domain gibt es einen eigenen DCV-Subnamespace, der individuell konfiguriert werden kann – ohne dass die produktiven Zonen jemals berührt werden.

Manueller Aufbau versus LEMARIT

Das DCV-Zonen-Konzept selbst ist nicht neu, wird aber in vielen Do-It-Yourself-Setups übersprungen, weil es eine zusätzliche Initial-Konfiguration erfordert. LEMARIT hebt diesen architektonischen Baustein aus dem Optional-Feature-Bereich heraus und erzwingt ihn strukturell: Alle Validierungen laufen ausschließlich über die dedizierten DCV-Zonen, die produktive Zone bleibt in jedem Fall unerreichbar.

LEMARIT als Anbieter mit nativer RFC-2136-Schnittstelle

Die LEMARIT-DNS-Infrastruktur unterstützt RFC 2136 nativ und ist so gebaut, dass die zentralen Sicherheits- und Automatisierungs-Herausforderungen strukturell adressiert sind – nicht als konfigurativer Zusatz, sondern als Architektur-Prinzip.

CA-Neutralität. Weil RFC 2136 ein herstellerneutraler Standard ist, funktioniert die LEMARIT-Schnittstelle mit jeder ACME-Client-Konfiguration – unabhängig davon, gegen welche Certificate Authority der Client validiert. In der Praxis bedeutet das: Sie können Let’s Encrypt, DigiCert, Sectigo, SSL.com oder eine beliebige andere ACME-fähige CA nutzen und trotzdem die LEMARIT-DNS-Schnittstelle für die DCV-Validierung einsetzen.

Erzwungene DCV-Zonen-Trennung. Wie oben beschrieben werden TSIG-Keys bei LEMARIT so ausgestellt, dass sie ausschließlich auf die dedizierte Validierungs-Zone schreiben können. Die produktive DNS-Zone bleibt architektonisch geschützt.

Zentrale Verwaltung. Alle TSIG-Keys werden zentral in der LEMARIT.app verwaltet – Erstellung, Rotation, Widerruf. Bei einem Sicherheits-Vorfall lässt sich ein Key sofort deaktivieren, ohne dass der Kunde die DNS-Konfiguration ändern muss. Ein Audit-Trail dokumentiert lückenlos, welcher Key wann welche Anfragen gestellt hat.

DV-, OV- oder EV. Unabhängig davon, ob Sie DV-, OV- oder EV-Zertifikate über die verschiedenen Validierungsstufen ausstellen lassen, funktioniert RFC 2136 gleichermaßen – die DCV-Antwort ist bei allen drei Levels technisch identisch.

Multi-Client-Kompatibilität. Die LEMARIT-RFC-2136-Schnittstelle ist auf allen drei etablierten ACME-Clients getestet: Certbot (via 
certbot-dns-rfc2136
-Plug-in), acme.sh (via 
nsupdate
-Hook) und cert-manager (via 
rfc2136
-Solver oder Webhook-Plugin für den LEMARIT-spezifischen Weg).

RFC 2136 in der Praxis – wo Sie konkrete Setups finden

Diese Seite behandelt die konzeptionellen und architektonischen Grundlagen. Für die praktische Umsetzung finden Sie in den weiterführenden Cluster-Pages Schritt-für-Schritt-Anleitungen für die drei etablierten ACME-Clients.

acme.sh mit LEMARIT RFC 2136 (empfohlen für schlanke Setups): Der

nsupdate

-Hook von acme.sh ist die minimal-invasivste Variante – acme.sh greift nicht in Server-Konfigurationen ein, sondern beschränkt sich auf die Zertifikats-Ausstellung. Details siehe ACME einrichten – acme.sh mit LEMARIT RFC 2136.

Certbot mit RFC 2136 (empfohlen bei bestehenden Certbot-Setups): Certbot bringt das 
certbot-dns-rfc2136
-Plug-in mit, das den TSIG-authentifizierten Update-Pfad direkt implementiert. Ein spezifisches Setup-Kapitel dazu folgt in Kürze.

cert-manager (empfohlen für Kubernetes): cert-manager unterstützt RFC 2136 nativ über den eingebauten

rfc2136

-Solver. Alternativ kann für die LEMARIT-Anbindung das Webhook-Plugin genutzt werden, das die DCV-Zonen-Verwaltung serverseitig übernimmt. Details siehe ACME einrichten – Kubernetes mit cert-manager.

Wann RFC 2136 der richtige Weg ist – und wann nicht

RFC 2136 ist nicht der einzige Weg zur DNS-01-Validierung, aber in einer klaren Menge an Szenarien der beste.

Klare Ja-Fälle

Wildcard-Zertifikate. Sobald 
*.example.com
oder Ähnliches benötigt wird, ist DNS-01 zwingend – und RFC 2136 ist der etablierte Standard-Pfad.

Server ohne offenen Port 80. Bei internen Anwendungen, hinter Reverse Proxies oder in strikt firewalled Netzwerken ist HTTP-01 oft nicht praktikabel. DNS-01 über RFC 2136 löst das Problem, ohne dass Netzwerk-Grenzen aufgebrochen werden müssen.

Multi-CA-Strategie. Wer heute Let’s Encrypt einsetzt, aber später zu DigiCert wechseln möchte (oder umgekehrt), profitiert davon, dass RFC 2136 CA-neutral ist. Der Wechsel bedeutet nur eine Anpassung des ACME-Endpoints, nicht der DNS-Setup-Logik.

Enterprise-Compliance-Umfeld. In Umgebungen mit ISO-27001-, NIS2-, DORA- oder KRITIS-Anforderungen ist die architektonische DCV-Trennung nicht nur ein Sicherheitsgewinn, sondern zunehmend eine Audit-Pflicht.

Weniger geeignete Fälle

Sehr kleine Setups mit einer einzigen Domain und ohne Wildcard-Bedarf. Hier ist HTTP-01 der einfachere Weg – kein DNS-Setup, kein TSIG-Key, kein DCV-Zonen-Konzept nötig.

Umgebungen ohne DNS-Kontrolle. Wenn Sie das DNS Ihrer Domain nicht selbst betreiben und Ihr DNS-Provider RFC 2136 nicht anbietet, bleibt Ihnen praktisch nur ein Provider-Plug-in oder – im LEMARIT-Kontext – die Migration der Domain zu einem RFC-2136-fähigen Anbieter.

Statische Legacy-Systeme. In Umgebungen, in denen kein moderner ACME-Client eingesetzt werden kann (etwa auf sehr alten Betriebssystemen), führt der Weg oft über eine externe Zertifikats-Ausstellungs-Architektur – hier ist die REST-API von LEMARIT die passendere Antwort.

ACME mit DNS-01 einrichten

Häufige Fragen (FAQ) zu ACME über RFC 2136

Ist RFC 2136 mit TSIG sicher genug für Enterprise-Umgebungen?

Ja – vorausgesetzt drei Bedingungen sind erfüllt: Der TSIG-Key wird mit 
hmac-sha256
(oder stärker) signiert, der Key hat begrenzte Schreibrechte (idealerweise nur auf eine DCV-Zone), und der Key-Wert wird sicher aufbewahrt (nicht im Plaintext-Konfigurationsordner). Bei LEMARIT sind alle drei Punkte architektonisch abgesichert.
Ein Provider-Plug-in nutzt die proprietäre API des jeweiligen DNS-Anbieters (Cloudflare, Route 53 usw.), typischerweise mit einem API-Token, das auf die gesamte DNS-Zone schreiben darf. RFC 2136 nutzt den herstellerneutralen IETF-Standard mit TSIG-Authentifizierung und kann architektonisch auf ein einzelnes Namespace beschränkt werden. Sicherheitstechnisch und wartungstechnisch ist RFC 2136 in den meisten Fällen die bessere Wahl.
Nur wenn Ihr Provider RFC 2136 unterstützt. Viele große DNS-Anbieter (Cloudflare, Route 53, DigitalOcean) tun das nicht – sie bieten stattdessen proprietäre APIs an. RFC-2136-fähige Anbieter sind typischerweise Enterprise-DNS-Provider wie LEMARIT oder klassische BIND-basierte Self-Hosting-Lösungen.
TSIG (Transaction Signature, RFC 2845) ist ein Protokoll zur kryptografischen Authentifizierung von DNS-Nachrichten. Es verwendet einen geteilten symmetrischen Schlüssel plus einen HMAC-Algorithmus (üblicherweise 
hmac-sha256
), um sicherzustellen, dass Update-Anfragen von einer autorisierten Quelle stammen und unterwegs nicht verändert wurden.
Das ACME-Protokoll (RFC 8555) definiert den Ablauf für die automatische Zertifikats-Ausstellung, inklusive dreier Validierungs-Verfahren: HTTP-01, DNS-01 und TLS-ALPN-01. RFC 2136 ist eine der möglichen technischen Umsetzungen der DNS-01-Challenge – konkret die Art, wie der ACME-Client den erforderlichen TXT-Eintrag im DNS setzt. ACME-Clients unterstützen typischerweise mehrere DNS-01-Backends; RFC 2136 ist eines davon und in vielen Fällen das robusteste.
LEMARIT stellt keine eigenen ACME-Clients zur Verfügung – die etablierten Open-Source-Clients (Certbot, acme.sh, cert-manager) sind Standard und werden von LEMARIT nativ unterstützt. LEMARIT liefert die serverseitige DNS-Infrastruktur mit RFC-2136-Schnittstelle, das DCV-Zonen-Konzept und die zentrale Key-Verwaltung.
Bei einem sauberen DCV-Zonen-Setup ist der Schaden strukturell begrenzt: Der Angreifer kann nur Validierungs-Einträge in der DCV-Zone setzen, nicht aber die produktive DNS-Zone manipulieren. In der LEMARIT.app können Sie einen Key sofort deaktivieren und neu ausstellen – die Zertifikats-Automatisierung läuft nach dem Key-Wechsel weiter, ohne dass die Kunden-DNS-Konfiguration angepasst werden muss.

Weiterführende Inhalte

SSL-Zertifikate automatisch verlängern
Enterprise Certificate Lifecycle Management

ACME-Challenges erklärt: DNS-01, HTTP-01, TLS-ALPN-01/

ACME einrichten: Schritt-für-Schritt-Anleitung

DV, OV, EV – die drei SSL-Validierungsstufen im Überblick
Close
Suchen