DNS Zone Changes: Delegation, Checks and Rollback

A DNS zone is a part of the namespace served under a particular administrative authority. When you move a zone or delegate a subdomain, first identify who controls the parent referral and who controls the child zone data. Prepare the child servers before sending traffic to them.

Then verify the referral, the child answers and the behavior of a resolver that clients actually use. A zone can look correct in its own editor while the parent is still referring queries elsewhere. This guide shows how to plan the change and capture the evidence needed to decide whether to continue or roll back.

Check the parent delegation and each child authoritative server separately; a cached recursive answer is not enough.

Draw the zone boundary and assign ownership

A DNS name can have several labels, but every label is not automatically a new zone. An organization might keep application names under example.com in a single zone, or it might delegate a branch such as apps.example.com to another team. In the second arrangement, the parent publishes a referral and the child serves its own zone data. The boundary matters because the teams may use different providers, credentials and change windows. List both owners before opening a ticket. Someone who can edit the child zone may have no way to change the parent referral.

Write the scope as a sentence that identifies the zone, the change and the clients affected. For example, an organization might move the authoritative hosting of apps.example.com to a new provider while keeping its public application names and answers intact. That is different from changing an individual A record or delegating the name for the first time. The verification should match the operation. A hosting move needs evidence that the referral changed and that the expected records remain available. A first delegation needs an explicit inventory of names that will move under the new administrative boundary.

Record the current parent and child name servers, where each set is managed and what the expected state will be after the change. Capture the zone apex SOA and NS records from authority, plus representative service records. Include an internal view if the organization serves different data to internal clients. Be explicit about whether the migration changes that view. A public recursive lookup cannot prove that a private network kept its intended answers.

Prepare the child servers before changing the referral

Load the intended zone data on the destination authoritative service. Review the records that users and applications rely on, including service aliases, mail routes, verification records and delegated subdomains where applicable. Use an inventory supplied by the zone owner. A single successful lookup can prove that one name is configured, but it cannot reveal that a less visible dependency was omitted. A useful baseline includes a known existing name, a deliberately absent test name where appropriate and the key service records identified by the application owners.

Query each intended server directly for the zone's SOA and representative records. Check that the answer is authoritative for the expected zone and that the serial and record data make sense for that deployment. In a conventional primary and secondary arrangement, differing serials may indicate that the latest zone has not reached every server. Look at the actual publication workflow before concluding that a serial difference proves a fault. Also verify that each listed endpoint can answer from the networks that need to reach it. An answer from a private management network does not prove reachability from external resolver networks.

Check the server names themselves. When a name server lives below the delegated name, a resolver may need address information supplied with the parent referral to reach it. This is the usual reason for glue in an in-domain delegation. Compare the intended glue with the actual addresses and confirm that the parent operator has the needed information. For an out-of-domain name server, verify that its address can be resolved through its own namespace. RFC 1034 describes referrals and the role of glue.

Decide what needs to happen to DNSSEC

Simplified DNSSEC trust link: validate the DS-to-DNSKEY match and the child signatures within the chain of trust.

Identify whether the existing delegation includes a DS record. If it does, determine how the destination provider will sign the child zone and how the parent and child changes will be coordinated. A validating resolver may reject answers when the parent DS no longer matches the signing state it discovers in the child. A direct query that returns a record can therefore look good while validation fails for users. Include a validating recursive resolver in the acceptance plan for a signed zone and document who owns the parent-side change.

The right sequence depends on the migration and the operators involved. Collect the provider's procedure and confirm the intended keys and DS records with the responsible parties. Avoid using a generic cutover order for every signed zone. Establish the current validation status, the state expected during the transition and the point at which old material can be removed. The team that can edit child zone records may not control the parent-side DS entry. Name that dependency and its owner in the change plan. RFC 4035 describes validation and the use of the DS record in the chain of trust.

Check the referral and the child as two separate steps

At cutover, verify the parent response for the delegated name. Record the name servers it returns and relevant address information. Compare that response to the approved target list. If it still refers to the old service, find out whether the change was accepted at the parent. A correct answer from a new child server cannot repair a referral that sends resolvers to different endpoints.

Then query the child servers directly. Check the zone apex SOA, NS records and several agreed service names. Confirm that the child answers authoritatively and that its data matches the expected version. If one server gives an authoritative answer and another refuses the same query, record each server separately. Resolve the difference before treating the delegation as healthy. A resolver can select among available servers, so a partial deployment can produce inconsistent results across otherwise similar clients.

Finally, query a recursive resolver from a representative client network. Where the domain is public, include an independent external vantage point. The result may differ temporarily from a direct parent or child probe because the resolver can have prior data in cache. Record the time, resolver and observed result so you can distinguish an expected transition from a persistent fault. For a private zone, use a resolver that has the relevant forwarding or authority configuration. Public probing cannot substitute for a test inside the intended resolution path.

Use the previous state to plan the cutover window

Before the change, capture what the old and new services will be able to answer while caches still contain the earlier delegation. In a hosting migration, keeping the old service reachable with compatible data through the transition can help resolvers that still use it. Determine that overlap with both providers and verify what they will serve during the window. If data can change during the overlap, assign one team to reconcile the two sets or agree to freeze changes temporarily. Otherwise, cached paths may continue reaching a different answer even when both sets of servers are healthy.

Record the TTLs that matter for the operation. Child record TTLs, parent referral TTLs and negative caching behavior are different pieces of the transition. Some of them may be controlled by a different operator. A request to lower a child A record TTL does not shorten an already cached parent referral. If the timeline relies on shorter cache retention, confirm which settings you control and when the older replies could have been cached. Use that information to set observation and rollback checkpoints.

When the application is served from several regions, ask each regional owner which resolver and service check represents their users. Add those checks to the same timeline. If one region still uses an earlier referral while another sees the new one, the timestamps and authority checks help distinguish a normal cache transition from a regional configuration error.

Rehearse rollback against a concrete failure

Save the prior state before editing. Close only after the parent and child checks pass; failed verification can trigger the agreed rollback plan, followed by another retest. Cached data may outlive either change.

Imagine that the new name servers answer correctly in direct tests, but a validating resolver reports a failure after the parent changes. Before rolling back, record the parent referral, the DS state and the child signing state so the teams can identify which part differs from the plan. Your rollback needs to describe what to restore at both sides of the boundary, who can do it and how to confirm the result. Restoring name server entries while leaving incompatible signing data in place may leave the failure in place.

Choose a stop condition that can be measured. Examples include a missing critical record on a destination server, repeated failures from the application network or a validation failure that the change owner cannot resolve within the window. Record an escalation owner and a latest decision time. If rollback is triggered, confirm that the old service still answers correctly, restore the agreed parent and child state, and repeat the parent, authority and recursive checks. Keep the evidence from before the rollback. It will help explain what happened even when clients recover at different times.

A closed change should show the expected and observed referral, child authority and client resolution. Include the tested name, type, endpoint, timestamp and result. Where application owners performed a separate service check, link that outcome to the DNS evidence. If you are comparing enterprise DNS deployment options, use ZDNS DNS product information as a starting point for discussing authority, verification and rollback requirements with the supplier.