Please note that the contents of this offline web site may be out of date. To access the most recent documentation visit the online version .
Note that links that point to online resources are green in color and will open in a new window.
We would love it if you could give us feedback about this material by filling this form (You have to be online to fill it)



Migrating a BIND Zone to Cloud DNS (command line)

This guide demonstrates how you would recreate a simple BIND DNS zone by using the gcloud command-line tool. If you need to migrate many zones or large sets of records, you might consider using Python instead .

Example.com BIND zone file

The following BIND DNS zone file is a simple example that uses some common practices, such as using the @ symbol to refer to the domain. This file will be transformed into the command-line requests in subsequent sections.

example.com.zone :

$TTL 36000
example.com. IN      SOA     ns1.example.com. hostmaster.example.com. (
                        2005081201      ; serial
                        28800           ; refresh (8 hours)
                        1800            ; retry (30 mins)
                        2592000         ; expire (30 days)
                        86400 )         ; minimum (1 day)

example.com.            86400   NS      ns1.example.com.
example.com.            86400   NS      ns2.example.com.
example.com.            86400   MX 10   mail.example.com.
example.com.            86400   MX 20   mail2.example.com.
example.com.            86400   A       192.168.10.10
ns1.example.com.        86400   A       192.168.1.10
ns2.example.com.        86400   A       192.168.1.20
mail.example.com.       86400   A       192.168.2.10
mail2.example.com.      86400   A       192.168.2.20
www2.example.com.       86400   A    192.168.10.20
www                     86400 CNAME     @
ftp.example.com.        86400 CNAME     @
webmail.example.com.    86400 CNAME     example.com.

The Google Cloud DNS API differs somewhat from the BIND syntax, for more information see BIND syntax differences .

Step 1: Configure your project and zone

  1. Install the Cloud SDK . If you already have the SDK installed, run the gcloud components update dns command to ensure that you have the DNS commands in your environment.

  2. Create or use an existing Google Developers Console project and enable the API:

    1. If you don't already have one, sign up for a Google account .
    2. Enable the Google Cloud DNS API in the Developers Console . You can choose an existing Compute Engine or App Engine project, or you can create a new project.
    3. If you need to make requests to the REST API, you will need to create an OAuth 2.0 ID:
      1. On the Credentials page in the APIs & Auth section, click Create new client ID .
      2. Choose Web application .
      3. In the Authorized JavaScript origins enter the host where you will serve this example, for example, http://localhost:8080 .
      4. Click Create Client ID .
    4. Note the following information in the project that you will need to input in later steps:
      • The client ID ( xxxxxx.apps.googleusercontent.com ).
      • The project ID that you wish to use. You can find the ID at the top of the Overview page in the Developers Console. You could also ask your user to provide the project name that they want to use in your app.

  3. If you have not run the gcloud tool previously, you will need to run the following command to authenticate and specify the project name from the Developers Console:

    gcloud auth login
    
  4. Create a managed zone. For this example, the zone is example.com , which is represented by the sample example.com.zone file . Similar to the BIND syntax, you must specify a period ( . ) at the end of host names.

    gcloud dns managed-zone create --dns_name="example.com." --description="Something descriptive" "myzonename"
    

    This command creates a zone in Cloud DNS to manage the records for example.com and is assigned an identifier of myzonename that you will use in later commands.

Creating the managed zone automatically creates a SOA record and a NS record in the zone for you. If you want to retain any settings from your SOA record, such as the administrator ( hostmaster.example.com. ), you can update these generated records in the next step.

Because Cloud DNS is providing the name servers for your zone, you do not need to create the records for ns1.example.com or ns2.example.com from the sample file. You can see these records by running the following command:

gcloud dns records --zone="myzonename" list

At this point, you have effectively recreated the first 10 lines from the BIND file.

Step 2: Create the records

Now that you have a managed zone with the basic SOA and NS records, you will recreate the remainder of the BIND file with the command-line tool. The input for the change request is a JSON object that can contain both additions and deletions in the same request.

Launch the records editor with the gcloud tool:

gcloud dns records --zone="myzonename" edit

The editor launches prefilled with an addition and a deletion of the SOA record. These prefilled changes are used to increment the serial number in the SOA record, which helps to prevent potential problems and for zone transfers. You might want to update your SOA record at this time to match the settings from your previous zone file, including changing the administrator, refresh, retry, expiration, and NXDomain values.

The following JSON object recreates the remainder of the sample BIND zone file. In the rrdatas fields, note that the hostnames must end with periods ( . ) to be fully-qualified DNS names.

{
  "additions": [
      {
          "kind": "dns#resourceRecordSet",
          "name": "example.com.",
          "rrdatas": [
              "10 mail.example.com.",
              "20 mail2.example.com."
          ],
          "ttl": 86400,
          "type": "MX"
      },
      {
          "kind": "dns#resourceRecordSet",
          "name": "mail.example.com.",
          "rrdatas": [
              "192.168.2.10"
          ],
          "ttl": 86400,
          "type": "A"
      },
      {
          "kind": "dns#resourceRecordSet",
          "name": "mail2.example.com.",
          "rrdatas": [
              "192.168.2.20"
          ],
          "ttl": 86400,
          "type": "A"
      },
      {
          "kind": "dns#resourceRecordSet",
          "name": "www2.example.com.",
          "rrdatas": [
              "192.168.2.20"
          ],
          "ttl": 86400,
          "type": "A"
      },
      {
          "kind": "dns#resourceRecordSet",
          "name": "www.example.com.",
          "rrdatas": [
              "example.com."
          ],
          "ttl": 86400,
          "type": "CNAME"
      },
      {
          "kind": "dns#resourceRecordSet",
          "name": "ftp.example.com.",
          "rrdatas": [
              "example.com."
          ],
          "ttl": 86400,
          "type": "CNAME"
      },
      {
          "kind": "dns#resourceRecordSet",
          "name": "webmail.example.com.",
          "rrdatas": [
              "example.com."
          ],
          "ttl": 86400,
          "type": "CNAME"
      },
      {
          "kind": "dns#resourceRecordSet",
          "name": "example.com.",
          "rrdatas": [
              "ns-cloud1.googledomains.com. dns-admin.google.com. 3 21600 3600 1209600 300"
          ],
          "ttl": 21600,
          "type": "SOA"
      }
  ],
  "deletions": [
      {
          "kind": "dns#resourceRecordSet",
          "name": "example.com.",
          "rrdatas": [
              "ns-cloud1.googledomains.com. dns-admin.google.com. 2 21600 3600 1209600 300"
          ],
          "ttl": 21600,
          "type": "SOA"
      }
  ]
}

Save the JSON object and close the editor. A successful request outputs the JSON object to the console and displays the id , startTime , and status fields of the change. You can check the status of the change by using the id in the next step.

Check the status of the request

You can check if the status of the record changes from the previous command by using the change ID with the following command:

gcloud dns changes --zone="myzonename" get <change_id>

Next steps

At this point, your Cloud DNS name servers are serving the zone data you configured on port 53 to anyone who asks. However, users of the DNS do not yet know that they should ask these name servers for all questions about example.com . To do this, you need to configure NS records for example.com in your registrar. See Updating your domain's name servers to use Cloud DNS for more information.

Authentication required

You need to be signed in with Google+ to do that.

Signing you in...

Google Developers needs your permission to do that.