Cloud DNS ResourceRecordSets API

1. Introduction

64e18005b6cdcd83.png

Last Updated: 2021-01-06

What is Cloud DNS?

See our homepage.

What you'll build

In this Codelab you will create a Cloud DNS ManagedZone and relevant ResourceRecordSets using gcloud to manage name resolution to some VM instance.

What you'll learn

How to CREATE, READ, DELETE and UPDATE individual ResourceRecordSets.

What you'll need

2. Getting set up

Set up your Google Cloud Platform Project

Login to gcloud

gcloud auth login

Create a project

gcloud projects create my-codelab-project

Enable the Cloud DNS API

gcloud services enable dns.googleapis.com

It may take a few minutes for this to take effect

3. Creating a private ManagedZone

A ManagedZone contains ResourceRecordSets.

Note the domain name that you want to add DNS records for. In this example, we'll use "my-domain.com" and assume your VM instance is on the default network.

gcloud dns managed-zones create my-zone \
    --description="ManagedZone for Cloud DNS ResourceRecordSets codelab." \
    --dns-name=my-domain.com. \
    --networks=default \
    --visibility=private

4. Manage ResourceRecordSets

By the end of this section DNS requests over your virtual private network for your domain will resolve to the VM's IP address.

For example, if your VM's IP address is "1.2.3.4", and you would like "my-domain.com." to resolve to that IP address, you must create an "A record".

CREATE an A record

gcloud dns record-sets create "my-domain.com." --type="A" --ttl="60" --rrdatas="1.2.3.4" --zone="my-zone"
  • The positional argument "my-domain.com." , a.k.a. dnsName, is the name we want to define DNS resolution for.
  • –type: denotes the DNS record type we are trying to create.
  • –ttl: denotes the time to live for this record.
  • –rrdatas: holds the actual answer to the query.
  • –zone: required to direct which ManagedZone this record should be created in.

Read more about DNS concepts here.

Now that you have created your A record, you should be able to test DNS resolution.

SSH into your machine. In this example we use a VM instance with the name "dns-codelab" in "us-central1-a"

gcloud compute ssh codelab --zone=us-central1-a

Install dnsutils so you can use the ‘dig' command

sudo apt install dnsutils

query your domain

dig my-domain.com.

this should produce output similar to

...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19979
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; QUESTION SECTION:
;my-domain.com.                        IN        A

;; ANSWER SECTION:
my-domain.com.                60        IN        A        1.2.3.4
...

CREATE, PATCH and GET a CNAME record

Now that you have mapped my-domain.com. to 1.2.3.4, you'll probably want to make sure that www.my-domain.com. also resolves to 1.2.3.4. Records for "www." prefixes are not created automatically.

If you query www.my-domain.com.

dig www.my-domain.com.

you'll get output similar to

...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61964
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
...

indicating that there is no DNS record for that domain

Rather than creating another A record, we should create a CNAME record which is a pointer to another record. This will prevent us from having to change both records in the event that we want to use a different IP address.

exit your VM inst

exit

Create CNAME record

gcloud dns record-sets create "www.my-domain.com." --type="CNAME" --ttl="60" --rrdatas="my-domin.com." --zone="my-zone"

Now that you have created your CNAME record, you should be able to test DNS resolution.

SSH into your machine again

gcloud compute ssh codelab --zone=us-central1-a

query your domain

dig www.my-domain.com.

you should have received output similar to

...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61964
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
...

Oh no! Looks like there was a typo when we were creating our CNAME record at the "–rrdatas" flag. Rather than deleting and recreating the record, we can patch in the correct change.

exit your VM instance

exit

Patch the CNAME record

gcloud dns record-sets update "www.my-domain.com." --type="CNAME" --rrdatas="my-domain.com." --zone="my-zone"

Note that we can omit the "–ttl" flag since we're not changing it, but all other flags must be included since they are part of the ResourceRecordSet's universally unique identifier.

We can also verify that the record is as expected using gcloud

gcloud dns record-sets describe "www.my-domain.com." --type="CNAME" --zone="my-zone"

which should produce output

NAME                    TYPE    TTL  DATA
www.my-domain.com.      CNAME   60  "my-domain.com."

verify that the CNAME record is resolving correctly

gcloud compute ssh codelab --zone=us-central1-a
dig www.my-domain.com.

you should have received output similar to

...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7471
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
...
;; QUESTION SECTION:
;www.my-domain.com.                IN        A

;; ANSWER SECTION:
www.my-domain.com.        60        IN        CNAME         my-domain.com..
...

DELETE to Clean Up

Before a ManagedZone can be deleted, all ResourceRecordSets within the ManagedZone must first be deleted (with the exception of NS and SOA records, which are automatically generated and must always exist in the ManagedZone).

exit your VM instance

exit

Delete the CNAME record

gcloud dns record-sets delete "www.my-domain.com." --type="CNAME" --zone="my-zone"

Delete the A record

gcloud dns record-sets delete "my-domain.com." --type="A" --zone="my-zone"

Delete the ManagedZone

gcloud dns managed-zones delete "my-zone"

5. Congratulations

Congratulations, you've successfully learned to manage your ResourceRecordSets!

Further reading

Reference docs