Use the secondary refresh endpoint when an owned zone is configured for the provider's supported native secondary DNS workflow. The refresh asks that server to obtain an updated zone from its configured primary. It does not convert a normal DNS API replica into an AXFR or IXFR secondary.
| Method | Resource | Scope | Idempotency-Key |
|---|---|---|---|
POST |
/v2/dns/zones/{zoneId}/slave/refresh |
dns:slave |
Required |
01 Check the transfer arrangement first
Confirm the zone's assigned server, zone type and permitted primary address. The primary must serve the zone and permit the secondary's actual transfer source. Where required, both ends must agree on TSIG authentication and other transfer settings. Ordinary website reachability does not establish that a zone transfer will succeed.
Check whether the primary has published the intended change and an appropriate SOA serial. A secondary cannot obtain a record that is absent from its configured source. Keep secondary data read-only unless you are deliberately changing the DNS architecture.
02 Request and verify a refresh
- Read the owned zone and confirm that the configured provider supports native secondary refresh.
- POST to the zone's
slave/refreshresource with the required scope and a unique idempotency key. - Retain the returned task or job identifier. Follow its state through the task endpoint instead of assuming the POST means the transfer has finished.
- Read the secondary's SOA directly and compare the relevant records with the primary.
- If the transfer failed, collect the provider error, primary and secondary addresses, expected serial and the time of the attempted refresh.
Common questions
Why do I have a replicated zone but no refresh capability?
Domain Nexus can replicate DNS through provider APIs, which is a different mechanism from a native secondary pulling AXFR or IXFR. Use the package replication workflow for API-managed copies.
Will a refresh fix incorrect records on the primary?
No. Correct the authoritative source and verify the new serial or provider state before asking a secondary to refresh.
Why does one nameserver still answer with old data?
It may be a different replica, a failed transfer, a source-selection mistake or an old cache. Query that nameserver directly and inspect its SOA. A resolver's cached answer cannot prove what a particular secondary currently serves.
When escalating, include the zone ID and server references, but keep shared transfer secrets and provider credentials out of tickets and screenshots.