DNS accounts: one place for Cloudflare and other provider keys

DNS accounts are the CMS's single place for storing Cloudflare and other DNS provider credentials. Whatever you put there is used by every plugin and module (Domain Manager, Cloud, Search Console…): if you change or add a key, it works everywhere at once, with no need to copy it into each one.

Why it exists

Before, each plugin kept its own copy of the Cloudflare token (in its settings, in the .env, in its own table…). That meant changing the key in several places whenever Cloudflare expired it or you revoked it, and a free module depending on a paid plugin just to read a key. Now there is a single registry in the CMS core, free of charge, and everything else reads from it.

Where to find it

In the superadmin panel: Settings → DNS accounts (/musedock/settings/dns-accounts). Each account shows its provider, name, reference (the Account ID on Cloudflare), the masked credential, the result of the last test and its status.

Adding an account

1. Click "Add account" and choose the provider.
2. Type a name you will recognise (for example, the company that owns the Cloudflare account).
3. Paste the token or keys that provider asks for.
4. On Cloudflare, also choose the role (Primary: your zones; Domains: customer domains; Read-only: lookups only) and the SSL mode for new domains.
5. Click "Save and test". The CMS stores the account encrypted and tests it with the provider right away; you will see a progress notice while it works.

For Cloudflare, create the token with permission to read zones (Zone → Zone → Read) and edit DNS (Zone → DNS → Edit) on the zones you want to manage. If you use Email Routing from the CMS, add its permission too.

Providers

Provider	What is stored	Automatic test
Cloudflare	API token (+ Account ID)	Yes: checks the token and counts the zones it sees
DigitalOcean, Hetzner, Vultr, Linode, Gandi	API token	Not yet
Porkbun	API key and Secret API key	Not yet
PowerDNS	API URL, API key and server ID	Not yet
Amazon Route53	Access key ID, Secret access key and region	Not yet
OVH	Endpoint, Application key/secret and Consumer key	Not yet
Namecheap	API user, API key, username and allowed IP	Not yet
RFC2136 (BIND)	Server, key name and secret, algorithm	Not yet

You can have several accounts of the same provider (for example, two Cloudflare accounts for two different companies) and of different providers. Each plugin decides which providers it knows how to use; today Search Console's domain setup and Domain Manager work with Cloudflare.

What you can do with each account

• Test (antenna icon): checks the connection and saves the result. With Cloudflare it also tells you how many zones it sees.
• Edit (pencil): change the name, role or key. If you leave a secret field empty the stored value is kept; if you type a new one, it is overwritten for all plugins.
• Default (star): the account used by default for that provider, for example for new domains.
• Enable / disable: a disabled account is kept but no plugin uses it.
• Delete: asks for your administrator password in a pop-up, because other plugins may depend on the account.

Importing the accounts you already had

The "Import existing accounts" button copies into the registry whatever was in Domain Manager (its old table) and the tokens in the .env. It is safe to repeat: it duplicates nothing and neither touches nor deletes the source. Each token is checked with Cloudflare before it is copied, and tokens Cloudflare rejects are not imported (you are told which).

Who uses these accounts

• Domain Manager: Cloudflare zones, DNS records, custom domains and Email Routing.
• Cloud: the hosting customers' domains.
• Search Console: publishes Google's verification TXT in the domain's zone.
• Any new plugin or module, just by asking the core service for the accounts.

Security

• Credentials are always stored encrypted with AES-256-GCM (authenticated encryption). The database never holds a token in plain text.
• Lists only show masked versions (cfut••••••2f53); the full key is never shown again.
• Encryption depends on APP_ENCRYPTION_KEY or APP_KEY in the .env. If you change that key, stored accounts can no longer be decrypted and show up as "Unreadable": you will have to type their tokens again.
• Tests never write the token to any log or error message.

One exception: Caddy, the web server that handles certificates, reads its token from /etc/default/caddy and cannot query the database. Domain Manager's "Save Cloudflare token" button updates the registry, the .env and Caddy at the same time; if you change the token only from DNS accounts, Caddy keeps using the old one until you sync it.

For developers

The registry is the service Screenart\Musedock\Services\DnsAccounts (table dns_provider_accounts). To find which account holds a domain's DNS and publish a record:

$registry = \Screenart\Musedock\Services\DnsAccounts::make();
$zones = new \Screenart\Musedock\Services\Dns\DnsZones($registry);

$found = $zones->locate('example.com');   // account + client + zone, or null
if ($found) {
    $found['client']->ensureTxt($found['zone']['id'], 'example.com', 'txt-value');
}

Do not read tokens from the .env or store your own: always ask the registry for the accounts. Adding another provider means implementing the DnsZoneClient interface and registering it in DnsZones::clientFor().

Frequently asked questions

What is the difference between "Enabled" and "Works"?

"Enabled" only means the CMS may use the account. "Works" is the result of the last test against the provider. An account can be enabled and still fail (for example, with an expired token): click the antenna to check.

What happens to the token I already have in the .env?

It is imported into the registry with "Import existing accounts" and from then on the CMS reads from the registry first. The .env is kept as a fallback and for Caddy; it is not deleted.

If I change a token here, do all plugins notice?

Yes. They all read the same account from the registry, so there is nowhere else to change it (except Caddy, see "Security").

Can I have several Cloudflare accounts?

Yes. When looking for a domain's zone, the CMS tries the enabled accounts and uses the one that holds it; an account with a broken token is skipped without affecting the others.

Troubleshooting

Symptom	Cause and fix
"Cloudflare responded 401" or "the token is not active"	The token was revoked or expired. Create a new one in Cloudflare and paste it using the account's pencil.
The test says "Sees 0 zones" or fewer than expected	The token lacks permissions or does not include those zones. Edit it in Cloudflare to add Zone → Read and DNS → Edit on the zones you need.
An account shows "Unreadable (did APP_KEY change?)"	The .env encryption key was changed after the account was saved. Edit it and type its token again.
"Import existing accounts" does not copy a token	Cloudflare rejects it (expired or revoked). The notice says which one; add a valid one with "Add account".
Adding a domain in Search Console says its DNS is in no account	Add here the Cloudflare account that holds that zone, or publish by hand the TXT record the panel shows.