Migrating to Cloud DNS

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 set up gcloud SDK.

Next, run the following command to specify the project name and authenticate with the Cloud 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 example:

• 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 managed zone.

To import record-sets, you use the dns record-sets import command. The --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

Caution: When importing record sets, if your zone file contains SOA records, you must use the --delete-all-existing flag to replace the SOA records provided by Cloud DNS. Otherwise, the update fails, since the imported records conflict with the pre-existing Cloud DNS records.

Note: Some DNS implementations and providers export BIND zone files without final periods on domain name data in CNAME, MX, PTR, and other records. In zone files Cloud DNS follows RFC standards and interprets all domain names without a final period as relative to the DNS name of the zone, so importing the following MX records into a zone with the DNS name example.com results in identical (and probably undesired) records for both:

    in.smtp              IN MX 5 gmail-smtp-in.l.google.com
    in.smtp.example.com. IN MX 5 gmail-smtp-in.l.google.com.example.com.

Check your zone files to ensure all names that need them have final periods before importing them.

Verify DNS propagation

You can use the Linux watch and dig commands to monitor and verify that your changes have been picked up by the Cloud DNS name servers.

Note: The watch and dig commands are not gcloud commands and are not used with the gcloud prefix. On non-Linux operating systems, you might need to install the watch and dig commands.

1. 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).

2. Check if the records are available on the name servers. Replace your_zone_nameserver with one of the name servers returned when you ran the previous command.

   watch dig example.com @your_zone_nameserver
   

3. Once you see your change, press Ctrl-C to exit.

The 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 Linux commands:

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.

If you're not using Linux, you can use the nslookup command.

Next steps

• Cloud DNS Overview
• gcloud command-line tool
• Managing Records
• Records Format (JSON)