Cloud DNS is GCP’s managed DNS service, but its real magic isn’t just about resolving names; it’s about how it integrates deeply with GCP’s networking and security, allowing you to manage your entire domain’s internet presence from a single pane of glass.
Let’s spin up a zone and add a record. We’ll use gcloud for this, as it’s the most direct way to interact with Cloud DNS.
# Create a managed zone for your domain
gcloud dns managed-zones create my-awesome-zone \
--description="My awesome domain zone" \
--dns-name="awesome-domain.com." \
--visibility="private"
# Add an A record to the zone
gcloud dns record-sets create "www.awesome-domain.com." \
--zone="my-awesome-zone" \
--type="A" \
--ttl="300" \
--rrdatas="192.0.2.1"
Here, my-awesome-zone is the internal name for our zone within GCP. --dns-name="awesome-domain.com." is the actual domain we’re managing. Notice the trailing dot – that’s crucial for fully qualified domain names in DNS. --visibility="private" means this zone will only be resolvable by VMs within your VPC network, which is great for internal services. If you wanted it public, you’d use --visibility="public".
The record-sets create command adds an A record for www.awesome-domain.com. pointing to 192.0.2.1. The ttl (Time To Live) of 300 seconds means that DNS resolvers will cache this record for five minutes.
Now, let’s see this in action. Imagine you have a web server on 192.0.2.1 that you want to make accessible internally within your GCP VPC. You’ve configured your awesome-domain.com. zone as private.
If you SSH into a Compute Engine instance within that VPC and try to curl the internal IP using the domain name:
curl http://www.awesome-domain.com.
Your VM, by default, will query its configured DNS server (which is usually a Google-provided internal DNS resolver). This resolver will then look up www.awesome-domain.com. within your my-awesome-zone and return 192.0.2.1. The curl command will then successfully connect to your web server.
The real power comes from how Cloud DNS interacts with other GCP services. For public zones, you’d associate them with your domain registrar. For private zones, they’re tied to your VPC network. This means you can manage DNS records for your internal applications without exposing them to the public internet. You can also use Cloud DNS for advanced scenarios like failover routing, where you point multiple IP addresses for the same hostname and configure health checks to automatically switch traffic to a healthy server.
The --visibility flag isn’t just a simple on/off. When you create a private zone, GCP automatically configures your VPC network’s DNS settings to use the Cloud DNS resolver. This means all VMs in that VPC will automatically query Cloud DNS for records within that zone. You don’t need to manually update /etc/resolv.conf on each VM.
One common point of confusion is the difference between a managed zone’s --dns-name and the FQDN of the record you’re creating. The --dns-name defines the suffix for records within that zone. So, if your --dns-name is example.com., you can create records like www.example.com. or app.example.com.. If you want to manage sub.example.com., you’d typically create a separate managed zone with --dns-name="sub.example.com.".
The most surprising thing is that Cloud DNS, when used for private zones, effectively becomes your VPC’s internal DNS server. It’s not just a place to store records; it’s an active participant in your network’s name resolution process, providing a highly available and scalable solution without you having to manage any DNS infrastructure yourself. You can even create alias records (ALIAS or ANAME records, though Cloud DNS implements them as CNAMEs that can point to specific GCP resources like Load Balancers) to point to GCP services directly, simplifying your DNS configuration further.
Once you’ve set up your private zone, the next thing you’ll likely run into is configuring your applications to use specific DNS servers for certain lookups, or dealing with cross-project DNS resolution.