DNScale is now available as a lego DNS provider

DNScale is now available in lego as DNS provider dnscale.

That gives teams a small, Go-native ACME client for issuing and renewing Let's Encrypt certificates through DNScale DNS-01. It is especially useful for wildcard certificates, origins behind edge proxies, internal services, and environments where port 80 is not reachable from the public internet.

What is lego?

lego is an ACME client and library written in Go. It supports DNS-01 providers directly, which lets it create the temporary _acme-challenge TXT record required by Let's Encrypt and other ACME-compatible CAs.

With DNScale support in lego v5+, lego can now:

• Create ACME challenge TXT records through the DNScale API
• Wait for DNS propagation
• Complete the ACME validation
• Clean up the challenge record
• Write certificate files that any TLS terminator can serve

This makes lego a good fit when you want one small binary instead of a larger certificate management stack.

Quick start

Create a zone-scoped DNScale API token, then run lego v5 or newer:

export DNSCALE_API_TOKEN="<your-token>"
 
lego \
  --accept-tos \
  --email admin@example.com \
  --dns dnscale \
  --domains example.com \
  --domains "*.example.com" \
  run

For Docker:

docker run --rm \
  -e DNSCALE_API_TOKEN="<your-token>" \
  -v "$PWD/.lego:/root/.lego" \
  goacme/lego:v5.2.0 \
  --accept-tos \
  --email admin@example.com \
  --dns dnscale \
  --domains example.com \
  --domains "*.example.com" \
  run

For production, test against Let's Encrypt staging first and store the token via DNSCALE_API_TOKEN_FILE or your secret manager. The full walkthrough is in lego DNS-01 with the DNScale DNS Provider.

Why DNS-01 matters

HTTP-01 is simple when a public web server can answer on port 80. DNS-01 is the better fit when the certificate target is not directly reachable by HTTP.

Common cases:

• Wildcard certificates such as *.example.com
• Edge-proxied origins where public validation traffic reaches a proxy instead of the origin
• Private or internal services that need publicly trusted certificates
• Mail, API, and infrastructure hosts that do not run a public HTTP listener
• Central certificate runners that renew certificates for multiple downstream services

The only public proof the CA needs is the ACME TXT record in DNS.

Use with Go-based products

Several infrastructure products are written in Go and integrate ACME automation, but the integration model matters.

Works today: lego CLI v5+

The standalone lego CLI works today with DNScale when you run lego v5 or newer.

Use this path when you want lego to write certificate files for nginx, HAProxy, Caddy, Traefik, Postfix, Dovecot, or another service:

DNSCALE_API_TOKEN_FILE=/etc/lego/dnscale-token lego \
  --accept-tos \
  --email admin@example.com \
  --dns dnscale \
  --path /var/lib/lego \
  --domains example.com \
  --domains "*.example.com" \
  renew

Then reload the service from a deploy hook:

--deploy-hook "systemctl reload nginx"

Version-gated: Traefik

Traefik uses lego internally for ACME DNS challenges. That means DNScale support arrives in Traefik only when the Traefik build embeds lego v5 or newer.

If your Traefik build still embeds lego v4, this configuration will fail because dnscale is unknown to that embedded provider list:

certificatesResolvers:
  letsencrypt:
    acme:
      email: admin@example.com
      storage: /data/acme.json
      dnsChallenge:
        provider: dnscale

Until your Traefik version includes lego v5+, use lego externally and point Traefik at the certificate files through the file provider:

tls:
  certificates:
    - certFile: /certs/example.com.crt
      keyFile: /certs/example.com.key

Separate module path: Caddy

Caddy does not use lego's DNS provider list for normal DNS-01 automation. Caddy uses CertMagic and Caddy DNS modules.

That means dns dnscale is not available just because lego has a DNScale provider. Until a native DNScale Caddy DNS module exists, use lego externally and configure Caddy with certificate files:

example.com, *.example.com {
  tls /var/lib/lego/certificates/example.com.crt /var/lib/lego/certificates/example.com.key
  reverse_proxy 127.0.0.1:8080
}

Operational notes

Use a dedicated DNScale API token for each certificate runner. Scope it to the zone it manages, and avoid reusing broad account-level credentials.

lego's DNScale provider supports:

Start with staging, then production:

lego \
  --server https://acme-staging-v02.api.letsencrypt.org/directory \
  --accept-tos \
  --email admin@example.com \
  --dns dnscale \
  --domains example.com \
  --domains "*.example.com" \
  run

If propagation checks are occasionally too fast for your environment, raise the timeout:

DNSCALE_PROPAGATION_TIMEOUT=120 \
DNSCALE_POLLING_INTERVAL=5 \
DNSCALE_API_TOKEN="<your-token>" \
lego --accept-tos --email admin@example.com --dns dnscale \
  --domains example.com --domains "*.example.com" run

Learn more

• lego DNS-01 with the DNScale DNS Provider
• Let's Encrypt DNS-01 Challenges with DNScale
• DNScale provider in the lego documentation
• lego releases

DNScale now fits cleanly into the lego ACME workflow: create a short-lived TXT record, pass validation, clean it up, and hand certificate files to whatever service terminates TLS in your stack.