Add optional JSON-based storage for dns_acmedns (alternative to multi-account comma-separated mode PR #2196)

[kubax]

PR Title

Add optional JSON-based storage for dns_acmedns (alternative to multi-account comma-separated mode PR #2196)

PR Description

Summary

This PR adds optional JSON-based storage support to the dns_acmedns plugin. A new variable, ACMEDNS_STORAGE, allows storing acme-dns account data (username, password, subdomain, server_url, fulldomain) in a JSON file. This enables clean handling of multiple acme-dns registrations without comma-separated lists.

The default behaviour (per-domain credential storage) remains unchanged.

Relation to PR #2196 (olee)

PR #2196 introduces multi-account support using comma-separated environment variables. This PR offers an alternative approach using structured JSON storage. Both approaches can coexist; this PR simply adds another option.

JSON Storage Format

The JSON file follows the same format used by other acme-dns clients (e.g., Certbot’s acme-dns plugin), ensuring easy migration and consistency.

{
  "example.com": {
    "server_url": "https://auth.acme-dns.io",
    "username": "user1",
    "password": "secret1",
    "subdomain": "0a1b2c3d",
    "fulldomain": "0a1b2c3d.auth.acme-dns.io"
  },
  "another.domain.com": {
    "server_url": "https://auth.internal.example",
    "username": "user2",
    "password": "secret2",
    "subdomain": "f4e5d6c7",
    "fulldomain": "f4e5d6c7.auth.internal.example"
  }
}

Features

• Optional JSON storage mode activated by setting ACMEDNS_STORAGE.
• Automatic per-domain account lookup based on the JSON file.
• Per-domain config now persists either:
  • credentials (default), or
  • the JSON storage path (new).
• Mutually exclusive modes to avoid configuration conflicts.
• Fully backward-compatible with existing setups.

Motivation

Users who manage many domains often also manage multiple acme-dns accounts. JSON storage provides a structured, scalable way to store these registrations in a single file, without relying on comma-separated lists or re-registration.

Compatibility

• No breaking changes.
• Existing setups continue working without modifications.
• JSON storage is fully optional and opt-in.

Note

This PR and the accompanying code were created with the assistance of ChatGPT, and all changes have been successfully tested in a live environment.

[github-actions]

Welcome
READ ME !!!!!
Read me !!!!!!
First thing: don't send PR to the master branch, please send to the dev branch instead.
Please read the DNS API Dev Guide.
You MUST pass the DNS-API-Test.
Then reply on this message, otherwise, your code will not be reviewed or merged.
Please also make sure to add/update the usage here: https://github.com/acmesh-official/acme.sh/wiki/dnsapi2
注意: 必须通过了 DNS-API-Test 才会被 review. 无论是修改, 还是新加的 dns api, 都必须确保通过这个测试.

[kubax]

Welcome READ ME !!!!! Read me !!!!!! First thing: don't send PR to the master branch, please send to the dev branch instead. Please read the DNS API Dev Guide. You MUST pass the DNS-API-Test. Then reply on this message, otherwise, your code will not be reviewed or merged. Please also make sure to add/update the usage here: https://github.com/acmesh-official/acme.sh/wiki/dnsapi2 注意: 必须通过了 DNS-API-Test 才会被 review. 无论是修改, 还是新加的 dns api, 都必须确保通过这个测试.

Thank you for the reminder regarding the DNS API Test.

I have attempted to run the DNS.yml workflow with valid repository secrets configured. However, the test consistently fails during the TXT-record update step. The acme-dns server responds with:

{"error": "bad_txt"}

My internal ACME infrastructure is not publicly reachable, so I cannot use our own acme-dns instance for the CI test. Because of this, I used the public acme-dns service at auth.acme-dns.io instead. That server, however, rejects the synthetic TXT values generated by the acmetest framework (for example, acmeTestTxtRecord_123456789) because they do not match its internal validTXT requirements. As a result, the DNS API Test cannot complete successfully.

Nevertheless, the updated dns_acmedns implementation works correctly in real-world usage with genuine ACME challenge tokens. I have tested the changes thoroughly in a live environment, and certificate issuance succeeds without issues.

In short:
The plugin implementation is functioning as intended, but the DNS API Test cannot pass because the synthetic TXT records used by acmetest are rejected by the public acme-dns server, and my own acme-dns system cannot be reached from GitHub Actions.

If needed, I can provide further details or logs.