SWAG · DuckDNS · TLS · Help

SWAG: DuckDNS returns KO for a wildcard certificate

Check the DuckDNS response, domain ownership and published TXT record when SWAG cannot renew its wildcard certificate.

Source date: 5 November 2026Editorial team: KAN KAI WORKSEditorially updated:

Quick answer

An HTTP 200 response containing “KO” does not confirm a successful DuckDNS update. Wildcard validation requires the expected DNS TXT record to be published. First establish whether setting or removing that record failed, then check the token and domain used by the running SWAG container. The documented report does not establish a general DuckDNS outage or prove a particular token problem.

Source basis: Q1 · Q2 · Q3

Applies to
Covers SWAG using DuckDNS for DNS-01 validation. The original report concerns SWAG 5.8.0-ls495 and does not establish a generally affected release range.
How to verify the result
The expected TXT record appears at the authoritative DNS service, a controlled certificate test succeeds, and the web service presents the intended certificate.
Your first check

Was the challenge TXT record actually published?

Compare the response body with the public TXT result. HTTP 200 alone does not establish that DuckDNS accepted the update.

SWAG is running, but certificate issuance or renewal stops at the DuckDNS step. The request shows HTTP 200 while its response body says KO. This combination appears in a specific SWAG incident report; it does not establish a general DuckDNS outage. A completed HTTP exchange and a successful DNS update are different observations. Q1

Identify the missing evidence

A wildcard certificate requires a DNS challenge with the expected TXT content. A working website or correct address record does not demonstrate that this separate record exists. Q3 Keep the current certificate and pause repeated production issuance attempts while the update step is already failing.

A focused diagnostic sequence

  1. Capture the relevant log section. Record the time, image tag, Certbot version and DNS plugin version. Include the first failure before KO, with tokens removed from URLs and environment values. Distinguish failure to create a record from failure to remove one after validation: both may occur in the same run.
  2. Match the domain to its account. In DuckDNS, confirm that the configured subdomain belongs to the account associated with the token. Check whitespace and which secret file the running container actually receives. A correct value in an old compose file does not prove that a replacement container loaded it.
  3. Check the intended SWAG configuration. Compare your settings with the documented DuckDNS validation mode. Avoid combining its configuration with variable names copied from an unrelated DNS plugin. Q2 Make one bounded configuration change at a time so that the result remains interpretable.
  4. Observe DNS during a controlled test. Query the intended _acme-challenge name against the responsible authoritative servers. Record the response and time. If the expected value never appears, investigate the update path. If it arrives later, measure that delay before changing propagation settings.
  5. Check competing jobs. Identify any other certificate clients using the same challenge name. Concurrent create and cleanup operations can interfere with an otherwise correct test. Do not remove unrelated TXT records just to simplify the display.

Act on the result

KO together with an unchanged record points towards the API or configuration path. A correct published value with failed validation calls for comparison of delegation, timing and the exact requested domain. Increasing a sleep interval cannot make a rejected API update succeed.

For support, prepare sanitised logs, the domain structure, image tag, validation mode and a timeline of DNS responses. Keep the token private. After a correction, verify issuance, a representative renewal test and the certificate actually served to visitors.

Frequently asked questions

Is HTTP 200 proof that DuckDNS accepted the change?

No. Inspect the response body and the resulting DNS record together.

Should I replace the token immediately?

First establish which account and domain it belongs to. Replacing a shared token can also affect other services.

Describe your case

Support with this issue

We can investigate the SWAG settings, DNS evidence and renewal sequence.

Describe your case →Related service: Data & improvements

Sources