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

For a conceptual overview of DNSSEC, seeDNSSEC overview.

Permissions required for this task

To perform this task, you must have been granted the following permissionsor 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 betweenoperators without incurring outages. Read this guide in full before youtransfer or migrate a zone. We recommend that you test the migration process ona 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 mustcoordinate the migration with both the DNS operators and the domain registrar.This step ensures that you can establish and maintain a valid chain oftrust from the parent zone to keys managed by both DNS operators during thetransition.

If your domain registrar also provides DNS hosting, you must coordinatewith your domain registrar to migrate the DNSSEC chain of trust. If theregistrar does not support this operation, you cannot migrate the name serverswhile maintaining the DNSSEC chain of trust.

Wait for resolver caches to expire

During migration, after you make critical record updates, wait for resolvercaches to expire. This step prevents validation errors caused by old cachedrecords inconsistent with the updated zone after migrating to the new nameservers.

Limitations

Migrating a DNSSEC zone has the following limitations:

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

• You must use the samealgorithmat both operators since zones must be signed with all algorithms in use. Fordetails, seeRFC 4035 section 2.2.Cloud DNS can only sign with one algorithm at a time. You cannotchange algorithms during migration between providers.

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

• You must be able to add a second DS record from Cloud DNS tothe parent zone. The registrar or parent zone must allow DS records thatcorrespond 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 operatorfor the zone until migration is complete. Cloud DNSautomatically stops key rotation for zones inTransfer 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.

Note: Because DNSSEC is deactivated during the transition, your zone is notsecure. Do not attempt zone migration if the zone contains anyrecord types that rely on DNSSEC authenticity and integrity guaranteesbecause migrating a zone in these conditions might cause loss of functionalityor security.

For an informative presentation about DNSSEC and domain transfers and potentialpitfalls, seeDNS/DNSSEC and Domain Transfers: Are theycompatible?.

Migration between operators

The technical approach that Cloud DNS uses for DNSSEC migrations isthe Double-DS KSK rollover variant described inRFC 6781 Appendix D AlternativeRollover Approach for Cooperating Operators.

DNSSEC migration works without exchanging private keys or signatures between DNSoperators. Instead, the existing name servers and parent zone pre-publishsigned records for the new operator's public keys in addition to the oldoperator's public keys. Likewise, the new name servers publish signed recordsfor 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 thetwo operators and the parent zone such that validating resolvers can use recordsfrom one operator to validate responses from the other operator. This processenables the transition to the new operator name servers without interruption.

After these records propagate, resolvers can validate responses from bothoperators during the subsequent transition period while the new name serverdelegation 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 oldoperator's trust anchor from the parent zone.

Migrate DNSSEC-signed zones to Cloud DNS

Before you begin,review all instructions. You must alsoverify that your provider supports migration. Otherwise youcannot 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 DNSSECTransfer state.Transfer state stops key rotation and allows DNSKEY import.

   You must use the samealgorithmsin 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 DNSSECrecord types from the existing zone (CDS, CDNSKEY, NSEC, NSEC3, NSEC3PARAM,or RRSIG types).

   You can import zones by using thegcloud dns record-setsimport command.

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

   You can also usedig ordelv to query for DNSKEY records, but you mustverify that the returned public keys are correct and valid for your zone.

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

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

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

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

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

9. Wait until the new records propagate and old records expire from allresolver 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.

   • The child zone NS record set TTL at the old operator expires.

   • The child zone DNSKEY record set TTL at the old operator expires.

10. Verify that the zone is ready by checking that the old operator isserving all the DNSKEY records and the parent zone is serving both DSrecords.

11. Change the name server delegations to point to Cloud DNS.

    Update the name server records at theregistrar to the Cloud DNS name servers for the new zone.

12. Wait until the new name server records propagate and old delegation recordsexpire from all resolver caches. Otherwise stale data might cause validationfailures.

    Wait until all of the following happen:

    • The parent zone NS record set TTL expires.

    • The child zone NS record set TTL at the old operator expires.

    After this step, you can safely stop serving the zone at the old operator.

13. Remove the old zone's DNSKEY records added to the Cloud DNS zone.

14. Change the DNSSEC state of the zone fromTransfer toOn.

    Leaving transfer state enables automatic key rotation for the zone. Yourzones can safely leave DNSSEC transfer state after a week, and must notremain in DNSSEC transfer state for more than a month or two.

15. Remove the DS record for the old operator's zone from your registrar.

Migrate DNSSEC-signed zones from Cloud DNS

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

To perform the migration, follow these steps:

1. Change the DNSSEC state fromOn toTransfer. This step stops key rotation.

2. Export your zone file and import it into the new operator.

   You can usegcloud dns record-sets export to export a zone.

   Exporting a zone inTransfer mode also exports DNSKEY records fromCloud DNS. If your provider accepts DNSKEY at this step, you caninclude them now and skip the steps below that transfer public keys fromCloud DNS to the new provider.

3. Sign the zone at the new provider.

   You must use the samealgorithmsin use by Cloud DNS at the new provider.

   You must stop key rotation for the zone at the new name server untilmigration completes.

4. Retrieve the DNSKEY records from Cloud DNS. InTransfermode DNSKEY records appear like normal records in the zone.

   You can also usedig ordelv to query the Cloud DNS nameservers for DNSKEY records, but you must verify that the returned publickeys are correct and valid for your zone.

5. Retrieve the new DNSKEY records from the new operator.

   You might have to first sign the zone or configure DNSSEC to obtain keys.

6. Add the Cloud DNS DNSKEY records to the new operator's zonein addition to the DNSKEY records for the new zone.

7. Add the DNSKEY records from the new operator to Cloud DNS.

8. Add the DS record for the new operator'szone to your registrar in addition to the existing DS record fromCloud DNS.

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

   Wait until all of the following happen:

   • The parent zone NS record set TTL expires.

   • The parent zone DS record set TTL expires.

   • The Cloud DNS zone NS record set TTL expires.

   • The Cloud DNS zone DNSKEY record set TTL expires.

   You can verify that the zone is ready by checking that Cloud DNS isserving all the DNSKEY records and the parent zone is serving both DSrecords.

10. Migrate the name server delegations to point to the new operator.

    Update the name server records at theregistrar to the new operator's name servers for the zone.

11. Wait until the new name server records propagate and old delegation recordsexpire from all resolver caches. Otherwise stale data might cause validationfailures.

    Wait until all of the following expire:

    • The parent zone NS record set TTL.

    • The Cloud DNS zone NS record set TTL.

    After this step, you can safely delete the zone from Cloud DNS.

12. Remove the Cloud DNS DNSKEY records added to the new zone.

13. Remove the DS record for Cloud DNSfrom your registrar.

14. Finish the migration at the new operator as needed.

If the other DNS operator has a process for migrating a DNSSEC-signed zone,you must perform their steps in parallel with this procedure, after step 1.

What's next

• To get information about specific DNSSEC configurations, seeUse advanced DNSSEC.
• To work with managed zones, seeCreate, modify, and delete zones.
• To find solutions for common issues that you might encounter when usingCloud DNS, seeTroubleshooting.
• To get an overview of Cloud DNS, seeCloud DNS overview.