Migrate or transfer DNSSEC-enabled zones

This page describes how to migrate a DNSSEC-enabled zone that is activated at the domain registrar between Cloud DNS and other DNS hosting providers while maintaining the DNSSEC chain of trust.

For a conceptual overview of DNSSEC, see DNSSEC overview.

Permissions required for this task

To perform this task, you must have been granted the following permissions or the following IAM roles.

Permissions

• dns.dnsKeys.create to create DNSKEYS
• dns.dnsKeys.delete to delete DNSKEYS
• dns.dnsKeys.list to list DNSKEYS
• dns.dnsKeys.update to update DNSKEYS

Roles

• roles/dns.admin

Before you begin

DNSSEC migration is complex and requires coordination to migrate a zone between operators without incurring outages. Read this guide in full before you transfer or migrate a zone. We recommend that you test the migration process on a less critical zone before attempting migration of critical production zones.

Coordinate with DNS operators and domain registrar

To prevent validating resolvers from treating the domain as invalid, you must coordinate the migration with both the DNS operators and the domain registrar. This step ensures that you can establish and maintain a valid chain of trust from the parent zone to keys managed by both DNS operators during the transition.

If your domain registrar also provides DNS hosting, you must coordinate with your domain registrar to migrate the DNSSEC chain of trust. If the registrar does not support this operation, you cannot migrate the name servers while maintaining the DNSSEC chain of trust.

Wait for resolver caches to expire

During migration, after you make critical record updates, wait for resolver caches to expire. This step prevents validation errors caused by old cached records inconsistent with the updated zone after migrating to the new name servers.

Limitations

Migrating a DNSSEC zone has the following limitations:

• You can only migrate a zone while maintaining the DNSSEC chain of trust if the new operator and registrar support DNSSEC migration, including importing DNSKEY records, setting multiple DS records, and preventing automatic key rotation during migration.

• You must use the same algorithm at both operators since zones must be signed with all algorithms in use. For details, see RFC 4035 section 2.2. Cloud DNS can only sign with one algorithm at a time. You cannot change algorithms during migration between providers.

• You must be able to import DNSKEY records from Cloud DNS into the other operator's zone and have those records signed with the operator's keys. Cloud DNS allows adding DNSKEY records for zones in Transfer mode.

• You must be able to add a second DS record from Cloud DNS to the parent zone. The registrar or parent zone must allow DS records that correspond to public keys that do not sign any records in the child zone.

• You must be able to stop automated key rotation by the old or new operator for the zone until migration is complete. Cloud DNS automatically stops key rotation for zones in Transfer mode.

If the new operator does not support migration, do the following:

1. Deactivate DNSSEC at your registrar.
2. Perform the transfer or migration.
3. Enable DNSSEC.
4. Activate DNSSEC at your registrar.

For an informative presentation about DNSSEC and domain transfers and potential pitfalls, see DNS/DNSSEC and Domain Transfers: Are they compatible?.

Migration between operators

The technical approach that Cloud DNS uses for DNSSEC migrations is the Double-DS KSK rollover variant described in RFC 6781 Appendix D Alternative Rollover Approach for Cooperating Operators.

DNSSEC migration works without exchanging private keys or signatures between DNS operators. Instead, the existing name servers and parent zone pre-publish signed records for the new operator's public keys in addition to the old operator's public keys. Likewise, the new name servers publish signed records for the old operator's keys in addition to the new operator's keys.

These keys from the other operator are signed, creating cross-trust between the two operators and the parent zone such that validating resolvers can use records from one operator to validate responses from the other operator. This process enables the transition to the new operator name servers without interruption.

After these records propagate, resolvers can validate responses from both operators during the subsequent transition period while the new name server delegation records propagate to all resolver caches.

After the updated name server records propagate, you can finalize the migration. You can remove the child zone from the old name servers and remove the old operator's trust anchor from the parent zone.

Migrate DNSSEC-signed zones to Cloud DNS

Before you begin, review all instructions. You must also verify that your provider supports migration. Otherwise you cannot migrate the zone using this process.

To perform the migration, follow these steps:

1. Stop all key rotation for the zone at the old name server.

2. Create a new DNSSEC-signed zone in DNSSEC Transfer state. Transfer state stops key rotation and allows DNSKEY import.

   You must use the same algorithms in use at the existing provider.

3. Export your unsigned zone files, and then import them into the new zone.

   Follow your provider's instructions for exporting zone data.

   You may include DNSKEYs at this step, but do not include any other DNSSEC record types from the existing zone (CDS, CDNSKEY, NSEC, NSEC3, NSEC3PARAM, or RRSIG types).

   You can import zones by using the gcloud dns record-sets import command.

4. Retrieve the previous DNSKEY records from the old name server.

   You can also use dig or delv to query for DNSKEY records, but you must verify that the returned public keys are correct and valid for your zone.

5. Retrieve the new DNSKEY records from Cloud DNS. In Transfer mode, DNSKEY records appear like normal records in the zone.

6. Add the existing DNSKEY records to the Cloud DNS zone in addition to the automatically generated DNSKEY records.

   You can also import DNSKEYs during step 3 and skip this step if your provider exports DNSKEYs along with the rest of the zone data.

7. Add the new DNSKEY records from Cloud DNS to the zone in the existing operator. Be sure to re-sign the zone if necessary.

8. Add the DS record for the Cloud DNS zone to your registrar in addition to the existing DS record.

9. Wait until the new records propagate and old records expire from all resolver caches. Otherwise stale data might cause validation failures.

   Wait until all of the following happen:

   • Records propagate to all name servers used by the old operator.

   • The parent zone NS record set TTL expires.

   • The parent zone DS record set TTL expires.