SWAG: DuckDNS meldet KO beim Wildcard-Zertifikat

Dein SWAG-Container startet, doch das Wildcard-Zertifikat wird nicht ausgestellt oder verlängert. Im Log steht bei der DuckDNS-Anfrage HTTP 200, gleichzeitig meldet der Inhalt KO. Genau diese Kombination wurde für eine konkrete SWAG-Installation gemeldet. Eine erfolgreiche HTTP-Verbindung ist hier kein Beleg für eine angenommene DNS-Änderung. Der Bericht belegt keine allgemeine Störung bei DuckDNS. Q1

Zuerst den fehlenden Nachweis finden

Ein Wildcard-Zertifikat braucht einen passenden DNS-Nachweis. Entscheidend ist der TXT-Inhalt am vorgesehenen Challenge-Namen. Die laufende Website und ihr A-Eintrag sagen darüber wenig aus. Q3 Vermeide wiederholte Produktionsanträge, solange der TXT-Schritt bereits scheitert. Das bestehende Zertifikat bleibt zunächst erhalten.

Prüfen, ohne Geheimnisse offenzulegen

1. Logabschnitt begrenzen. Sichere Zeitpunkt, Container-Image, Certbot- und DNS-Plugin-Version sowie den Fehler unmittelbar vor KO. Entferne Tokens aus URLs und Umgebungsvariablen, bevor du etwas weitergibst. Unterscheide fehlgeschlagenes Setzen von fehlgeschlagenem Aufräumen: Beides kann im selben Ablauf erscheinen.
2. Domain und Konto zuordnen. Kontrolliere im DuckDNS-Konto, ob genau die konfigurierte Subdomain zu diesem Token gehört. Prüfe Schreibweise, versehentliche Leerzeichen und die nach einem Containerwechsel tatsächlich geladene Secret-Datei. Ein vorhandener alter Wert beweist nicht, dass der neue Container ihn nutzt.
3. SWAG-Modus abgleichen. Vergleiche die Einstellungen mit der DuckDNS-Anleitung für deine Installation. SWAG dokumentiert dafür einen eigenen Validierungsmodus. Vermische diesen nicht mit einem beliebigen anderen DNS-Plugin und dessen Variablennamen. Q2
4. DNS-Ergebnis beobachten. Frage während eines kontrollierten Tests den vorgesehenen _acme-challenge-Namen bei den zuständigen Nameservern ab. Notiere Wert und Zeitpunkt. Bleibt der neue Wert aus, liegt der Schwerpunkt beim Update. Erscheint er erst später, muss die Wartezeit zur beobachteten Verteilung passen.
5. Zweiten Lauf erst nach Befund. Prüfe Erneuerung in einer geeigneten Testumgebung. Mehrere gleichzeitig laufende Clients können einander TXT-Werte überschreiben; vergleiche deshalb auch die übrigen Erneuerungsjobs.

Welcher Befund führt wohin?

Bei KO und unverändertem DNS ist der API-/Konfigurationsweg zu untersuchen. Bei sichtbarem richtigen TXT-Wert, aber weiterhin fehlender Validierung, gehören Delegation, Abfragezeit und angeforderter Domainname in den Vergleich. Ein längerer Sleep repariert kein abgewiesenes Update.

Für eine Übergabe helfen bereinigte Logs, Domainstruktur, Image-Tag, verwendeter Modus und die zeitliche Folge der DNS-Antworten. Teile niemals das Token. Nach der Korrektur müssen Ausstellung, Erneuerung und das tatsächlich ausgelieferte Zertifikat zusammenpassen.

Häufige Fragen

Bedeutet HTTP 200, dass DuckDNS alles akzeptiert hat?

Hier nicht: Der Antwortinhalt und der tatsächliche DNS-Eintrag müssen ebenfalls stimmen.

Soll ich sofort ein neues Token erzeugen?

Erst die Zuordnung prüfen. Ein Austausch betrifft möglicherweise weitere Systeme und sollte kontrolliert erfolgen.

Fall beschreiben