Skip to content

Knowledgebase

Build and validate a reviewable DNS changeset

domain-nexus, development

A changeset records the exact DNS edits you intend to make so they can be validated and reviewed before publication. Start from a current zone and record read. For an existing record, retain its returned record_key rather than calculating a new identifier from the replacement content.

01 Build the draft

Method Resource Scope Idempotency-Key
GET /v2/dns/zones/{zoneId}/records dns:read Not required by this route
POST /v2/dns/zones/{zoneId}/changesets dns:write Required
POST /v2/dns/changesets/{changesetId}/validate dns:write Required
PATCH /v2/dns/changesets/{changesetId} dns:write Required
  1. Read the zone version and the complete required record collection, following pagination.
  2. Prepare a non-empty operations list using add, update, delete or replace. Each new value uses a record object; after is an accepted alternative.
  3. Include base_row_version from the reviewed zone and a meaningful summary. Describe destructive work accurately.
  4. POST the draft with an idempotency key and retain both the submitted items and returned changeset ID.
  5. Call validate while the changeset is still a draft. Review any record errors before moving to approval and application.

A small add operation can look like:

Structured data example
{
  "base_row_version": 7,
  "summary": "Verify DNS integration on an owned test zone",
  "operations": [
    {
      "operation": "add",
      "record": {
        "name": "_dn-test",
        "type": "TXT",
        "content": "integration-check",
        "ttl": 300
      }
    }
  ]
}

The sample version 7 is illustrative. Replace it with the row_version returned for the zone you just reviewed, so the changeset records that reviewed state. Do not hard-code the sample version for later requests.

Can I patch the draft's record items afterward?

The current changeset PATCH changes its summary only. If the intended records change, create a newly reviewed draft instead of assuming an items field will replace the stored operations.

Does validation guarantee successful publication?

No. Record validation is one stage. Provider support, ownership, locks, current-zone conflicts and required approval remain relevant at application time. More than 25 items defaults to requiring approval; other protections can also apply.

For deletes and replacements, keep the before-state evidence and review record ownership carefully. A request containing a valid record identifier can still be wrong for the business task. Preserve unrelated mail, service verification and protected records unless their removal is explicitly intended.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support