1. Read the owned zone and its current version, lock reason and expiry.
2. For a metadata update, send only supported fields such as default_ttl, with the current If-Match version where available.
3. For a management lock, POST a useful reason and optional locked_until. Choose the actual operational purpose, such as a planned migration review.
4. Save the result and read the zone again to confirm the intended state.
5. Before clearing a lock, resolve the reason it was applied. Submit the lock DELETE only through an identity with approval scope.

No. This endpoint is not a zone rename, package reassignment or provider migration shortcut. Use the controlled migration or provisioning workflow for those tasks, including ownership and capability review.

Do not assume it changes explicit TTLs already set on individual records or forces resolver caches to expire. Inspect the actual desired record set and use a reviewed changeset when those record TTLs must change. Previously cached answers keep the TTL applicable when they were cached.

A lock may protect a hosting handoff, provider conflict or recovery action. Clearing it without understanding that state can allow new writes during an unresolved transition. Use a clear reason and a deliberate expiry where appropriate so future operators can make an informed decision.

If an optimistic-version conflict occurs, re-read the current object and compare the intervening change. Do not remove the version check simply to overwrite another administrator's lock decision. Record the final request reference with the maintenance task.

• Change a DNS package master without confusing replication and delegation
• Preview and execute a controlled DNS-server migration through the API
• Distinguish registrar transfer lock, registry lock and DNS management lock
• Retry Domain Nexus requests without creating duplicate domain operations