Skip to content

Knowledgebase

Run a controlled DNS provider acceptance check before assigning customer packages

domain-nexus, domains-dns

A useful provider acceptance check proves the exact operations your package will use. It starts with a zone you control and ends with verified authoritative answers. Run it for a new connection, a changed credential, a provider migration or a major change to the package's intended capabilities.

01 Prepare a controlled test

Use a test domain or delegated subdomain owned by your organisation. Record the existing DNS and ensure the test will not alter production mail or website traffic. Select a test customer and package whose entitlement and limits match the intended service. Do not use another customer's zone merely because the API credential can see it.

02 Exercise the required operations

  1. Save the provider connection and run its connection check. Read the detail, including any indication that no zone was available to test.
  2. If the package creates zones, create an authorised test zone and verify the exact provider resource. If the adapter manages only existing zones, prepare and link one through the supported workflow.
  3. Read the complete record list. Add a temporary TXT record, modify its value and remove it, verifying each provider readback.
  4. Export the records and, where backups are enabled, create a test backup. Review the restore preview without restoring over unrelated changes.
  5. For replication, inspect every selected target. For secondary DNS, test its transfer workflow separately from ordinary primary-record editing.
  6. Query the authoritative nameservers and compare registrar delegation. If testing DNSSEC, verify the provider signing state and parent DS chain.

What should the result record contain?

Keep the connection label, provider account, tested package, zone, operation times, task references and observed results. Record which features were actually exercised. A successful TXT change does not prove reverse DNS authority, DNSSEC key management or website forwarding deployment.

When should I stop?

Stop the affected test if reads are incomplete, ownership is ambiguous or the provider outcome is uncertain. Reconcile the state before another mutation. You do not need to exercise destructive production deletion to prove a connection is useful; test only the lifecycle operations that the proposed service requires on disposable owned resources.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support