Cloud DNS supports the migration of an existing DNS domain from another DNS provider to Cloud DNS. This procedure describes how to complete the necessary steps: creating a managed zone for your domain, importing your existing DNS configuration, and updating your registrar's name service records.
Before you begin
If you have not used the
gcloud command-line tool before, first
Next, run the following command to specify the project name and authenticate with the GCP Console:
gcloud auth login
You can also specify the
--project parameter for a command to operate against
a different project for that invocation.
Create a managed zone
To migrate an existing domain, first create a managed zone to contain your DNS records. Note that when you create a zone, the new zone won't be used until you update your domain registration, explicitly point some resolver at it, or directly query one of your zone's name servers.
To create a zone, provide the DNS zone name, a description, and a name to identify the zone:
gcloud dns managed-zones create --dns-name="example.com." --description="A zone" "examplezonename"
Export your DNS configuration from your existing provider
Consult your provider's documentation to learn how to export your zone file. Cloud DNS supports the import of zone files in BIND or YAML records format.
- For Dyn, go to Download Your Zone File.
- AWS Route 53 does not support export. Instead, you can use the open source cli53 tool.
Import the record set
Once you have the exported file from your other provider, you can use the
gcloud dns record-sets import command to import it into your
To import record-sets, you use the
dns record-sets import command.
--zone-file-format flag tells
import to expect a BIND zone
formatted file. If you omit this flag,
import expects a YAML-formatted records file:
gcloud dns record-sets import -z=examplezonename --zone-file-format path-to-example-zone-file
Verify DNS propagation
You can use the Linux
dig commands to monitor and verify that your
changes have been picked up by the Cloud DNS name servers. Note that
dig are not
gcloud commands and are not used with the
gcloud prefix. On
other operating systems, you might need to install the
Look up your zone's Cloud DNS name servers:
gcloud dns managed-zones describe examplezonename
The output looks something like this:
nameServers: - ns-cloud-a1.googledomains.com. - ns-cloud-a2.googledomains.com. - ns-cloud-a3.googledomains.com. - ns-cloud-a4.googledomains.com.
In the output, the letter following the "ns-cloud-" part of the name is referred to as the name server shard. As documented here, there are five such shards (letters A-E).
Check if the records are available on the name servers. Replace
your_zone_nameserverwith one of the name servers returned when you ran the previous command.
watch dig example.com @your_zone_nameserver
Once you see your change, press
watch command runs the
dig command every 2 seconds by default. You
can use this command to determine when your authoritative name server picks up your
change, which should happen within 120 seconds.
Update your registrar's name server records
Log into your registrar provider and change the name server records to point to the name servers you saw in the prior step. At the same time, make a note of the time to live (TTL) your registrar has set on the records. That tells you how long you have to wait before the new name servers begin to be used.
Wait for changes, then verify
To get the authoritative name servers for your domain on the Internet, run the following:
dig +short NS example.com
If the output shows that all changes have propagated, you're done. If not, you can check intermittently or you can automatically run the command every 2 seconds while you wait for the name servers to change. To do that, run the following:
watch dig +short NS example.com
Ctrl-C exits the command.