1. Read the owned zone and confirm the package permits backups and has retention capacity.
2. POST to its backups resource with the required idempotency key.
3. Store the returned task reference and wait for the backup operation's final state.
4. List the zone's retained backups, following the returned pagination metadata.
5. Identify the completed snapshot by zone, time and available status evidence. Do not rely only on the request's acceptance time.
6. Download the selected backup through its authenticated resource and store it in an access-controlled recovery location.

The backup download returns content as a binary download rather than the normal JSON success envelope. Inspect the response status and content type before saving it, because an API problem response should not be stored as if it were a valid backup file.

No. This route uses authenticated backup scope and ownership checks. Connector artifact grants are a separate API workflow. Do not share a secret-bearing API request URL as a public backup link.

No. Retention, package policy, provider availability and later changes can affect recovery. Keep the snapshot's context and test a restore preview when planning a recovery. A downloaded DNS backup also may not reproduce every provider-specific proxy or routing feature.

If a backup task fails because the provider cannot be read reliably, resolve that failure before starting a destructive change. An empty or incomplete snapshot is not a useful safety copy. Keep the task and backup references together with the change request so the correct restore point can be found without guessing from filenames.

• Approve a current backup restore preview before changing DNS
• Track DNS jobs without mistaking a queued task for a published answer
• Export BIND zone text and verify its SHA-256 digest
• Back up and restore DNS records
• Build a renewal action list from the renewal-risk endpoint