Replace the credential saved in PD BIND 9 DNS after the server administrator prepares its replacement. Changing an authorised server key does not automatically update the provider in your billing panel.

Identify the intended access

Open BIND 9 DNS → Providers and confirm the server, SSH username and authentication method. Ask the server administrator which integrations share that account and how the credential change will affect them.

An SSH public key authorised at the server and the private key supplied to the module have different roles. Put the private key only in the intended credential field and private storage. For compatibility across supported installations, request an appropriate RSA key rather than assuming every available key format is supported.

Replace and verify

1. Have the server administrator prepare the replacement access through their supported process.
2. Keep working access during verification where the server’s authorised-key arrangement permits it.
3. Edit the matching provider and replace SSH private key or SSH password, as appropriate.
4. Run Test connection and save the intended provider.
5. Read a known zone and verify the required management access.
6. Ask the administrator to retire obsolete access only after its other uses are understood.

Do not paste a public key into the private-key field or send either credential in a ticket. Password changes may invalidate shared consumers immediately; coordinate those changes deliberately.

Diagnose a refusal

Separate authentication errors from directory permissions, required tool access and zone activation. A passing connection test does not prove every file is writable or every zone is served. Retain the exact redacted result and action time if verification fails; use the connection guide rather than repeatedly replacing credentials to fix a different problem.

See the PD BIND 9 DNS Blesta guide for related tasks, or explore the module.