Professional Cloud Network Engineer
Cloud DNS is Google's managed Domain Name System (DNS) service, which translates human-readable domain names into IP addresses. A managed zone in Cloud DNS holds resource record sets, which are the instructions that tell DNS how to resolve a query. The service supports standard records for basic mapping and advanced routing policies for intelligent traffic distribution.
A resource record is a single mapping within a DNS zone. Cloud DNS supports several common types. An A record maps a domain name to an IPv4 address, while an AAAA record maps to an IPv6 address. A CNAME record creates an alias, pointing one domain name to another. A PTR record is used for reverse DNS lookups, mapping an IP address back to a domain name. A CAA record specifies which certificate authorities can issue SSL/TLS certificates for the domain, enhancing security. Cloud DNS also offers an ALIAS record, a special type that functions like a CNAME but can be placed at the root of a domain (the zone apex), where normal CNAMEs are not allowed.
You create records inside a managed zone. Each record requires a DNS name, a record type, a Time to Live (TTL) value, and the record data. The TTL controls how long other DNS servers cache the record. Changes to records are made through transactions, which ensure multiple updates are applied together atomically. You can manage records via the Google Cloud console or the gcloud dns record-sets command-line tools.
Weighted round robin (WRR) is a routing policy that distributes DNS queries across multiple backend targets based on assigned weights. Each target receives a share of traffic proportional to its weight. For example, a target with a weight of 80 receives 80% of the traffic, while a target with a weight of 20 receives 20%. This policy can be combined with health checks so traffic is only sent to healthy targets.
Geolocation routing directs queries to different IP addresses based on the geographic location of the user making the query. You configure specific IP addresses for regions like us-central1 or asia-east1. When a query arrives, Cloud DNS identifies the user's region and returns the corresponding IPs. If a region has no healthy endpoints, you can configure it to either fail over to a backup region or, with geofencing enabled, continue sending traffic to the nearest region regardless of health.
Failover routing provides high availability by automatically switching traffic from a set of primary targets to backup targets when the primaries fail health checks. You configure primary targets with health checks and define backup targets, often using geolocation routing for the fallback. The trickle traffic feature allows you to send a small, defined percentage of traffic (e.g., 10%) to the backup targets even when the primaries are healthy, which is useful for testing backup systems.
Health checks are crucial for advanced routing policies. When you enable health checking for a policy, you must point the policy to a Cloud Load Balancing forwarding rule, not a raw IP address. Cloud DNS then monitors the health of all endpoints behind that forwarding rule. Only targets that pass their health checks are included in DNS responses, ensuring users are not directed to broken services.
A DNS zone is a container for the records of a specific domain. Cloud DNS supports different zone types to fit various network architectures, controlling who can resolve the names within them and where the queries are sent.
A public DNS zone hosts records that are accessible and resolvable from the public internet. You use a public zone to manage the DNS for websites or services that need to be reached globally. Once created, its records are served by Google's infrastructure to any internet user.
A private DNS zone is only resolvable from within specified Virtual Private Cloud (VPC) networks. You bind the zone to one or more VPCs during creation. This creates a trust boundary, as only resources inside those authorized VPCs can resolve the names in the zone. A common use is to create a private zone for an internal service like a database, then add an A record pointing the service's name to a private IP address.
DNS peering and forwarding zones connect DNS resolution across separate networks. DNS peering allows VPC networks in different Google Cloud projects to resolve each other's private zones, enabling two-way name resolution without merging the networks. A forwarding zone sends queries for a specific domain (like onprem.example.com) to a designated DNS server, such as one in another VPC or an on-premises network. You choose peering for bidirectional resolution between VPCs and forwarding to route queries for specific domains to an external resolver.
Beyond basic resolution, Cloud DNS provides tools for security, traffic filtering, and administrative control across complex environments.
A Cloud DNS Response Policy (RPZ) lets you intercept and modify the response to DNS queries based on rules. You can block, redirect, or provide custom answers for queries matching certain domain patterns. These policies are bound to VPC networks or Google Kubernetes Engine (GKE) clusters, allowing you to enforce security or routing rules before normal DNS resolution occurs. You manage the full lifecycle of these policies using the gcloud dns response-policies commands or the Cloud Console.
Resolution scopes define where a DNS record or policy is visible. Cloud DNS follows a hierarchy: it first looks for matches within the most specific scope (like a GKE cluster), then broader scopes (like the VPC network). Zonal Cloud DNS is a deployment model that confines a private zone's failure domain to a single Google Cloud zone. This provides isolation, so an outage in one zone does not affect DNS resolution in others, which is different from global Cloud DNS zones that are visible across an entire VPC.
In a Shared VPC setup, cross-project binding allows a service project to create its own private DNS zone and bind it directly to the shared host VPC. This gives the service project team autonomy to manage their internal DNS records without needing permissions in the host project. Resources in any project attached to the Shared VPC can resolve records from these bound zones.
Access to Cloud DNS resources is controlled by Identity and Access Management (IAM) roles. The DNS Administrator role provides full control over all DNS resources. The DNS Reader role grants read-only access. Specialized roles like DNS Peer are needed to set up DNS peering, while permissions like dns.networks.bindPrivateDNSZone are required to bind a zone to a VPC in another project. The Cloud DNS Service Agent role allows internal Google Cloud services to interact with DNS on your behalf.
Both CNAME and ALIAS records create an alias from one domain name to another. The key difference is that a CNAME record cannot be placed at the root of a domain (the zone apex, like example.com), while an ALIAS record can. Cloud DNS internally resolves the ALIAS target and returns the final IP address to the client.
Use a public zone for domains that need to be resolved from the public internet, such as your company website. Use a private zone for internal service names (like database.internal) that should only be resolvable from within your private Google Cloud VPC networks, keeping them hidden from the internet.
In geolocation routing, you assign specific IP addresses to different geographic regions. If health checks are enabled and all endpoints in a user's region become unhealthy, Cloud DNS can fail over the query. It will either direct the user to the next nearest healthy region (default) or, if geofencing is enabled, continue to return the IPs for the nearest region even if they are unhealthy.
Cross-project binding allows a service project in a Shared VPC environment to create and manage its own private DNS zone and attach it directly to the shared host VPC network. This enables decentralized DNS management, letting each team control their internal records without requiring permissions in the central host project.
Prepare and test your skills
Prepare and test your skills