Cloud DNS Study Notes
Cloud DNS is Google Cloud's managed, authoritative Domain Name System service for publishing DNS zones and records for your domains. It also provides private zones, forwarding, and peering features that control name resolution inside VPC networks, making it both a public DNS host and an internal name-resolution tool tested on the ACE exam.
Key facts
- A managed zone is the container for DNS records for one DNS name suffix, such as example.com, and can be public for the internet or private for selected VPC networks.
- Public zones are served from Google's global anycast network for low-latency resolution worldwide, and require registrar delegation to Google's assigned name servers to go live.
- Private zones are visible only to authorised VPC networks you bind to them, letting internal services resolve names like db.internal.example.com without exposing them publicly.
- Cloud DNS supports standard record types including A, AAAA, CNAME, MX, TXT, NS, and SRV, with changes managed through transactions in gcloud or the console.
- DNS peering lets one VPC use the name resolution of another VPC's private zones, while forwarding zones send queries for a suffix to specific on-premises or external name servers.
- Split-horizon DNS uses a private zone with the same name as a public zone so internal clients receive private addresses while external clients receive public addresses.
- Response Policy zones allow custom local responses and override behaviour for bound VPCs, useful for blocking or redirecting specific names internally.
- Cloud DNS integrates with Cloud Logging for query logs on private zones and policies, which helps troubleshoot resolution problems inside hybrid environments.
- Private zones do not automatically work over VPN or Interconnect for on-premises clients; on-premises resolution usually needs an inbound forwarding server policy or Cloud DNS server policies.
What the exam expects you to know
- Distinguish public zones for internet resolution from private zones bound to VPCs for internal-only names, and pick split horizon when both audiences need different answers.
- Know that creating a public zone does nothing until the registrar NS records point to Cloud DNS name servers assigned to that zone.
- Identify forwarding zones as the solution when VPC clients must resolve names hosted on-premises, and peering zones when they must resolve another VPC's private zone.
- Recognise server policies with inbound forwarding as the way to let on-premises DNS servers query Google Cloud private zones over VPN or Interconnect.
- Understand CNAME restrictions, especially that a CNAME cannot coexist with other record types at the same name and cannot be used at a zone apex.
- Spot DNS as the wrong layer for health-based failover; Cloud DNS alone does not remove unhealthy backends like a load balancer health check does.
Cloud DNS vs Registrar or On-Premises DNS: when to use which
Use Cloud DNS when you want DNS managed in the same project and IAM model as your Google Cloud resources, with API and gcloud automation, private zones integrated with VPCs, and global anycast serving for public zones. Keep a registrar's DNS or an existing on-premises system when corporate policy centralises DNS elsewhere, but then you lose private zone, peering, and server policy features. Exam scenarios mentioning internal-only hostnames, split horizon, or forwarding to on-premises almost always require Cloud DNS features that a basic registrar DNS service cannot provide at all. See also the Registrar or On-Premises DNS notes.
Useful gcloud commands
gcloud dns managed-zones create my-zone --dns-name=example.com. --visibility=public
gcloud dns record-sets create www.example.com. --zone=my-zone --type=A --ttl=300 --rrdatas=203.0.113.10
gcloud dns managed-zones list
gcloud dns record-sets list --zone=my-zoneCommon exam traps
- Trap: Creating a private zone and expecting on-premises hosts to resolve it automatically. On-premises access needs inbound forwarding configuration and routes for the forwarding addresses.
- Trap: Forgetting registrar delegation for public zones. Records in Cloud DNS are invisible to the internet until the domain's NS records point to Google's servers.
- Trap: Binding a private zone to the wrong VPC or no VPC. A private zone resolves only for the VPC networks explicitly authorised to use it.
- Trap: Using the same record name in overlapping private and peering setups and expecting both answers; zone precedence rules decide which zone answers for a VPC.
Frequently asked questions
What is the difference between a public and a private Cloud DNS zone?
A public zone is an authoritative zone answerable by anyone on the internet once the registrar delegates to Google's name servers. A private zone with the same DNS name is visible only inside the VPC networks you bind to it, returning internal addresses or internal-only records. Using both together creates split-horizon DNS for different internal and external answers.
How do on-premises systems resolve Google Cloud private zone names?
You create an inbound forwarding entry point by configuring a server policy with inbound forwarding on the VPC. That gives you forwarding IP addresses in the VPC that on-premises DNS servers can query over Cloud VPN or Cloud Interconnect. Without that policy and the supporting routes and firewall rules, private zones remain resolvable only from inside Google Cloud.
What is a DNS forwarding zone in Cloud DNS?
A forwarding zone sends all queries for its DNS suffix to a set of target name servers you specify instead of answering from local records. It is the standard pattern for hybrid DNS, where instances in Google Cloud need to resolve corporate domain names hosted on on-premises DNS servers, while other domains continue to resolve normally through Google Cloud.
Study aid disclaimer: Cloud Cert Notes is an independent educational study aid. It is not affiliated with, endorsed by, or sponsored by Google, Microsoft, Amazon, Oracle, or Alibaba. Google Cloud, Associate Cloud Engineer, and Cloud Digital Leader are trademarks of Google LLC; all other certification names and product names are trademarks of their respective owners. Always confirm service details against the official provider documentation before sitting an exam.