1. Introduction
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!