Moving a signed zone is a coordinated trust transition. The registrar may control delegation and DS changes, while the old and new DNS providers control zone data and signing keys. A successful import does not prove that validating resolvers can follow every intermediate state.
Inventory the old trust path
References: RFC 6781 §4.3.5.
Export ordinary records, DNSKEY and DS data, signing configuration, relevant TTLs and authority addresses. Record who can change parent NS and DS data. Confirm whether the new provider supports importing existing keys, coordinated signing or only a new independent key set. Do not export private signing keys unless an approved secure procedure and compatible providers require it.
Before choosing a migration method, test that the new authorities serve the full zone consistently. Include MX, selectors, authentication TXT and TLSA records. Preserve negative-answer behavior and existing delegations. A newly healthy DNSSEC chain does not compensate for missing mail records.
Choose a documented transition
References: RFC 6781 §4.1, RFC 6781 §4.3.5, RFC 8767 §4.
RFC 6781 describes DNSSEC rollover and operator-change considerations. There is no safe universal sequence independent of provider capabilities. A coordinated transition may keep old and new validation paths usable while cached DS, DNSKEY and NS information overlaps. If the providers cannot support the selected approach, arrange a documented transition with them rather than inventing a timing shortcut.
A deliberate signed-to-unsigned-to-signed migration is a security downgrade with its own dependency order and waiting periods. Parent DS must not continue pointing to an unusable child key. Conversely, adding a new DS before the corresponding signed child is reachable can create failures. Lowering TTL just before switching does not shorten the lifetime of records already cached with an older TTL. RFC 8767 permits stale serving under specified refresh-failure conditions; do not treat TTL expiry alone as proof that every dependent path has retired the old data.
Rehearse incompatible cached states
References: RFC 6781 §4.3.5, RFC 4035 §5.
Build a disposable parent and two authoritative child services. Define old DS/key A and new DS/key B, plus fixed MX and TLSA test data. Test at least four resolver states: old delegation with old trust data, new delegation with compatible trust data, old cached DS with new-only keys, and new cached DS with old-only keys. The last two are deliberate incompatibility cases, not acceptable transition states.
For each state retain parent DS, child DNSKEY and RRSIG data, resolver cache setup, clock, exact query and validator trace. Repeat before, during and after the chosen overlap. Check certificate-to-TLSA association separately if the mail endpoint changes. These are requirements for a resolver-based migration test. The retained offline cryptographic matrix below covers signed-data compatibility only, not a live migration.
Make rollback a trust operation
References: RFC 6781 §4.3.5, RFC 4035 §5.
Changing NS back does not flush cached DS or DNSKEY information. A rollback plan must specify which keys remain available and which cached combinations still validate. Keep the old service and required signing material available for the approved overlap, with monitored retirement criteria rather than a convenient calendar date.
After cutover, compare every authoritative server, multiple relevant resolver paths and representative email tests. Confirm validation after the expected cache transitions, then retire old infrastructure through the change process. Preserve the exact final DS and delegation evidence so the next operator can explain the resulting trust path.
Observed synthetic migration matrix
References: RFC 4035 §5.
A retained 7 November 2026 cryptographic lab, inspected but not rerun for this review, tested seven signed-data states. Old DS/key A, overlapping A/B DS with key A, overlapping DS with key B, and final DS/key B all validated. Old-only DS with new-only key B failed, as did rollback to key A after replacing the DS with B alone. Restoring matching A material validated again. These are actual signature and DS checks with generated test keys, not simulated pass labels. They demonstrate incompatible cached-data combinations but do not emulate a resolver cache, provider API or elapsed TTL transition. Live provider migration, timing and rollback execution remain pending.