If a PowerDNS v4 connection authenticates and lists zones but cannot save a record, investigate the write path before changing the API key. Domain Nexus's PowerDNS and PowerDNS v4 choices use the same Authoritative API client. Changing the provider label does not turn a read-only backend into a writable one.
Why can PowerDNS API reads work while zone writes fail?
- Record the failing zone, task reference, requested record and HTTP status from the available diagnostic evidence.
- Read the server and the exact zone using the existing connection. Confirm API URL does not already include the path that the adapter adds, and that Server ID matches the service.
- Ask the PowerDNS administrator which backend serves this zone. The PowerDNS BIND backend exposes its zone data for API reads but does not provide ordinary API record editing. Other backends may also have different feature support.
- Check whether an API reverse proxy allows the required write methods. Zone reconciliation uses a PATCH request containing record-set replacements and deletions, not only GET requests.
- Confirm the zone's role. A secondary that receives transfers from elsewhere should not be edited as if it were the primary. Resolve a provider role conflict before applying changes.
01 Choose a supported remedy
For a deliberately read-only service, use Domain Nexus permissions that match that role and keep edits at the real authoritative source. If you need API-managed primary zones, plan a move to a supported writable backend with a reviewed record export and rollback point. That is a DNS service migration, not a reason to edit production database tables manually.
For a blocked proxy method or inadequate key, repair only the required access, then repeat one controlled TXT change. Read the provider's record set and query the authoritative nameserver before reopening customer writes. If the provider accepted a change but the response was lost, reconcile the actual zone before retrying.
The same diagnosis applies to DNSSEC cryptokey operations: successful record reads do not prove key-management access. Leave parent DS records unchanged until you have verified the provider-side signing state and a valid migration plan.