Use DNS Manager > Servers to connect Domain Nexus to the authoritative DNS systems your company operates. A saved connection identifies a backend and its credentials. Packages then determine which customers and zones can use it.
IN THIS ARTICLE
01 Prepare the connection
Choose the actual provider from the public connection list. Prepare the endpoint or account identifier, provider-specific API credential and any source-IP restrictions. Create credentials with the permissions required for your intended work: reading zones, editing records, creating zones or operating special features are not always the same permission.
For a customer-owned existing zone, confirm that the provider account grants access to that exact zone. Owning the domain at a registrar does not automatically give an unrelated DNS API account permission to edit it.
02 Add and test
- Open Servers and choose the add-server action. Give the connection a recognisable label, including the account or location where useful.
- Select the provider type. Complete the fields presented for that driver. Do not copy credentials into a different provider type merely because both accept an API token.
- Configure the permitted DNS features and the server's advertised nameservers where required. Use the actual authoritative hostnames supplied or operated for that backend.
- Save the configuration and use Test & enable. Resolve authentication, endpoint, certificate or account-selection errors before assigning the server widely.
- Attach the connection to a controlled DNS package and test an owned zone. Check a read, a harmless record write and, if needed, zone creation and deletion separately.
Does a successful provider connection test prove that DNS works?
A connection test confirms the checks it performs. It does not establish that every zone belongs to the credential or that every record type is writable. A provider may allow record editing but prohibit creating zones, or support DNSSEC only for a particular zone type.
Read the saved record back from the provider and query the authoritative nameservers. If public DNS still uses a different network, the test zone can be managed successfully without affecting visitors. Change registrar delegation only after the destination zone is complete.
03 Handle errors precisely
For an authentication failure, check the correct account, token expiry and allowed source addresses. For a permission failure, compare the attempted action with the credential's privileges. For a timeout, inspect reachability and provider status before repeating writes.
Keep a credential-rotation record and test replacement credentials before revoking the old token. Removing a server from a package is different from deleting the remote zone; review the relevant workflow before cleanup.