Design, implement, and secure Google Cloud networks, from VPCs and hybrid connectivity to load balancing and Cloud Armor, and track your readiness for the Professional Cloud Network Engineer exam.
Prepare and test your skills
Prepare and test your skills
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.
DNS peering enables two-way name resolution between private zones in different Virtual Private Cloud (VPC) networks without merging the networks. Conversely, a forwarding zone routes queries for a specific domain to a designated external DNS server, such as one in an on-premises network or another VPC.
Cloud DNS requires advanced routing policies with health checks to point to a Cloud Load Balancing forwarding rule rather than a raw IP address. Cloud DNS monitors the endpoints behind that forwarding rule and only includes healthy targets in DNS responses.
Trickle traffic sends a small, configurable percentage of traffic to backup targets even while primary targets remain healthy. This allows administrators to continuously test and validate the readiness of backup systems.
Response Policy Zones intercept and alter DNS query responses based on rules that can block, redirect, or provide custom answers for matching domain patterns. These policies attach to Virtual Private Cloud (VPC) networks or Google Kubernetes Engine (GKE) clusters to enforce administrative or security controls before normal DNS resolution occurs.
Last updated