# DNSSEC-enabled event domain: migration handoff record

Use this with the domain registrar, the old and new DNS operators, and the qualified DNS change owner. It is a decision and evidence record, not a cross-provider command sequence. Follow the providers' current documentation for the exact domain and zone.

## 1. Scope and current state

| Field | Confirmed value / evidence |
| --- | --- |
| Registered domain and event services depending on it | |
| Planned nameserver or registrar change; separate these if both are changing | |
| Change owner, backup and approval time | |
| Current registrar / parent-zone contact and authority to change DS | |
| Old DNS operator and support contact | |
| New DNS operator and support contact | |
| Current parent DS record set and evidence time | |
| Current authoritative DNSKEY/signing state and evidence time | |
| Relevant parent NS/DS and child NS/DNSKEY cache lifetimes (from actual data) | |
| Services using DNSSEC-dependent records such as DANE/TLSA, if any | |
| Website, registration, ticketing aliases, MX and mail-authentication records to compare | |

## 2. Select a provider-supported path

| Capability or decision | Old operator | New operator | Registrar/parent | Owner/evidence |
| --- | --- | --- | --- | --- |
| Published process for a DNSSEC-signed zone migration | | | | |
| Coexistence or multi-signer support, including cross-published public keys | | | | |
| Multiple DS records accepted while needed | | | | |
| Compatible signing algorithm and key-rotation control | | | | |
| Provider-supported path if chain cannot be preserved | | | | |
| Conditions under which DNSSEC would be temporarily inactive | | | | |
| Review of services that depend on DNSSEC authenticity | | | | |

**Approved path and exact provider guide/version:**

**Reason the alternative path is unsuitable:**

**Qualified DNS reviewer and approval:**

Google Cloud documents a coordinated cross-operator path only when all required capabilities are present. Route 53's hosted-zone migration guide instead tells operators to remove the parent DS before its move and re-establish trust afterwards. Do not splice these procedures or treat either as a universal sequence.

## 3. Change gates and evidence

- [ ] Zone contents and live services match the approved inventory on both providers.
- [ ] The operator tested the planned path on a less critical zone when feasible.
- [ ] The parent DS and child DNSKEY relationship was checked from authoritative sources, not only a dashboard.
- [ ] The team has a documented wait criterion based on actual parent/child cache lifetimes, not a fixed number copied from another domain.
- [ ] Both the event site and email dependencies have owners during the transition.
- [ ] A rollback decision owner and provider-supported recovery path are recorded before delegation changes.
- [ ] The old operator remains available until the chosen provider guide says it is safe to retire.
- [ ] After each gate, validating resolvers and real event tasks were checked; failures and time zones were recorded.

| Gate / observed time and zone | Parent DS | Old/new authoritative DNSKEY and answers | Validating resolver result | Site, registration and email check | Decision and approver |
| --- | --- | --- | --- | --- | --- |
| Before any change | | | | | |
| Before nameserver delegation | | | | | |
| During transition | | | | | |
| Before retiring old zone | | | | | |
| After final trust state | | | | | |

**Final owner for registrar DS, DNS signing, key rotation and monitoring:**

**Evidence archive and next review date:**

If the chosen path temporarily deactivates DNSSEC, describe that as a security and functionality tradeoff for this domain. If a dependency such as DANE/TLSA relies on DNSSEC, obtain expert review before using that path. Never promise zero downtime from a worksheet.