Read a domain's desired nameservers through the v2 API

1. Authenticate with domains:read permission.
2. Resolve the exact domain's identifier from /v2/domains.
3. Send the nameserver GET request and read its collection.
4. Follow any returned pagination metadata and preserve the full hostnames.

GET /v2/domains/DOMAIN_ID/nameservers

The current handler filters this collection to the desired source. It does not perform an independent live observation of registrar delegation for each read. A saved intended list can therefore differ temporarily from a pending provider operation or public cached data.

In a private server-side integration, use the server-side PHP request helper in the API getting-started article with domains:read access. Replace DOMAIN_ID with the domain's returned public identifier. The GET request does not submit a nameserver change.

$domainId = 'DOMAIN_ID';
$result = nabtechRequest('GET', '/v2/domains/' . rawurlencode($domainId) . '/nameservers');
if ($result['http_status'] !== 200) {
    throw new RuntimeException('Could not read desired nameservers.');
}
$desiredNameservers = $result['response']['data'] ?? null;

// Separate workstation check:
// dig +trace example.com NS

Read the result: The API collection describes the desired nameserver records stored by Domain Nexus. Compare that intent with the parent delegation observed independently. A difference can reflect a pending or failed operation, or old delegation still cached at a resolver.

Do not repeatedly resubmit the intended list just because a normal recursive lookup is old. Check the existing operation and target-zone readiness. Nameserver changes do not copy website, mail or DNSSEC data to the destination DNS provider.

Check the most recent nameserver operation and domain synchronization. Then inspect parent delegation and query the authoritative servers directly. Recursive resolvers may still hold older delegation until cached information expires.

This distinction matters during a migration. The target DNS provider can hold a complete zone before the registry delegates to it, and the API can store a desired change before the registrar confirms it.

Changing nameservers selects the authoritative DNS service. It does not copy the old zone's website, mail or verification records. Before preparing a PUT request, ensure every destination authority serves the intended records and that DNSSEC has a valid transition plan.

Ordinary NS records added inside a forward zone are not automatically a registrar delegation change. They may instead delegate a child subdomain. Use the correct workflow for the task.

Confirm that your credential belongs to the correct reseller, that the identifier refers to the intended domain and that no change is pending. Check whether the application is displaying an old cached API response.

If the desired list is correct but public DNS is wrong, investigate the provider operation, registry state and DS records. Rewriting the same desired values repeatedly is unlikely to fix an unresolved upstream failure.

• Replace a domain's authoritative nameservers through the v2 API
• Get started with the current Nabtech Domain Nexus v2 API
• Check DNS propagation and find the source of an old answer
• Operate DNSSEC from zone signing through parent DS verification

• ISC BIND: dig and delv reference