Professional Cloud Network Engineer
Cloud DNS is Google's managed Domain Name System (DNS) service that translates domain names into IP addresses. A managed zone is a container for all the DNS records of a specific domain. You manage different types of records and advanced routing policies within these zones to control how traffic is distributed.
A resource record is a single instruction inside a DNS zone. Cloud DNS supports several standard 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 from one domain name to another. An ALIAS record is a special Cloud DNS record that works like a CNAME but can be placed at the root of a domain, where normal CNAMEs are not allowed. Other important records include the PTR record for reverse DNS lookups and the CAA record, which specifies which certificate authorities can issue SSL/TLS certificates for the domain.
You create and update records inside a managed zone. Each record requires a DNS name, a record type, a Time to Live (TTL) value that controls caching duration, and the record data like an IP address. Changes are made through transactions, which ensure multiple updates are applied together as a single unit. You can manage records using 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. Traffic is split proportionally; for example, a target with a weight of 80 receives 80% of the queries. This policy can be combined with health checks to ensure traffic is only sent to healthy endpoints.
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. If health checks are enabled and all endpoints in a user's region become unhealthy, Cloud DNS can fail over the query to a backup region. With geofencing enabled, it can instead continue returning IPs for 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. The trickle traffic feature allows you to send a small percentage of traffic (e.g., 10%) to the backup targets even when primaries are healthy, which is useful for testing backup systems.
Health checks are essential for advanced routing policies like failover and weighted routing. 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 and includes only healthy targets in its DNS responses.
A DNS zone's type controls who can resolve the names within it and where queries are sent. Cloud DNS supports several zone types to fit different network architectures.
A public DNS zone hosts records that are accessible and resolvable from the public internet. You use public zones for domains that need to be reached globally, such as a company website. 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, creating a trust boundary. Only resources inside those authorized VPCs can resolve the names, which is ideal for internal services like a database with 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 without merging the networks. A forwarding zone sends queries for a specific domain (like onprem.example.com) to a designated DNS server in another VPC or an on-premises network. You choose peering for bidirectional resolution and forwarding to route queries to an external resolver.
Cloud DNS provides tools for security, traffic filtering, and administrative control beyond basic name resolution.
A Cloud DNS Response Policy (RPZ) lets you intercept and modify DNS query responses 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, enforcing security or routing rules before normal DNS resolution occurs.
Resolution scopes define where a DNS record or policy is visible. Cloud DNS follows a hierarchy, checking the most specific scope (like a GKE cluster) first before 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, providing isolation so an outage in one zone does not affect DNS resolution in others.
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 is controlled by Identity and Access Management (IAM) roles. The DNS Administrator role provides full control. The DNS Reader role grants read-only access. Specialized roles like DNS Peer are needed to set up DNS peering, and permissions like dns.networks.bindPrivateDNSZone are required to bind a zone to a VPC in another project.
Before moving DNS zones to Cloud DNS, you must validate that all existing records will work. This involves exporting zone files from the source, confirming record types, and ensuring TTL values fit the timeline. In hybrid environments, you must verify that DNS forwarding works between on-premises and VPC networks and that firewalls allow DNS traffic on port 53.
The cutover method decides how DNS resolution switches from the old provider to Cloud DNS. A big bang cutover updates the parent zone's nameserver records all at once, offering a clean switch but risking complete failure if Cloud DNS is misconfigured. A phased cutover uses forwarding rules or weighted round robin routing to gradually shift a percentage of traffic, allowing testing before full commitment.
After switching, you must confirm DNS resolution works from all networks: on-premises, VPCs, and the public internet for public zones. In hybrid designs, ensure external DNS zones forward requests correctly and firewall rules allow traffic between external networks. Verify that Cloud DNS handles CNAME records correctly based on zone type.
A Cloud DNS failover policy routes traffic to a primary endpoint pool and switches to a backup pool only when the primary targets fail. You configure it by defining primary and backup record sets in a managed zone and attaching a health check to the primary set. For hybrid environments, health check probes require network paths across Cloud VPN or Cloud Interconnect to reach on-premises backends.
The default fallback behavior triggers only when every endpoint in the primary health-checked record set is unhealthy. If at least one primary endpoint remains healthy, Cloud DNS continues using the primary set. When all primaries fail, Cloud DNS immediately returns the IPs from the backup set. The policy does not support automatic cascading to tertiary targets. Ingress firewalls must allow Google's health check probe IP ranges (35.191.0.0/16 and 130.211.0.0/22).
Troubleshooting requires tracing query paths across network boundaries. A private zone only resolves for authorized VPC networks. To resolve on-premises hostnames, you configure forwarding zones or outbound server policies pointing to on-premises DNS servers. Hybrid interconnects and VPN tunnels must maintain valid routes and permit bidirectional traffic on port 53 (UDP and TCP). Responses from external DNS servers must return to the exact Google Cloud IP that sent the query.
Cloud DNS evaluates routing policies differently for public versus private zones. Public zones evaluate policies for clients querying from the internet, while private zones evaluate only for queries originating inside attached VPCs. Inconsistent resolution occurs if private zone attachments omit peered VPCs or hybrid networks that need access. Maintaining parity requires binding private zones to all relevant VPCs and keeping policy definitions synchronized.
You enable DNSSEC for a managed public zone using the gcloud dns managed-zones update command with the --dnssec-state on flag. You must specify the algorithm and key length for both the Key Signing Key (KSK) and the Zone Signing Key (ZSK). Cloud DNS supports RSASHA256, RSASHA512, ECDSAP256SHA256, and ECDSAP384SHA384. If you don't specify, it defaults to RSASHA256 with a 2048-bit KSK and a 1024-bit ZSK.
The choice involves a tradeoff. RSA algorithms like RSASHA256 are widely supported by older resolvers. ECDSA algorithms produce smaller signatures, leading to faster computation and smaller response packets, but are only supported by newer systems. Using different algorithms for the KSK and ZSK is discouraged as it can cause validation failures.
To change DNSSEC settings after enabling, you must first disable DNSSEC, make the changes, and then re-enable it. A critical dependency exists with your domain registrar: if you want your domain to resolve while DNSSEC is disabled in Cloud DNS, you must first deactivate DNSSEC at the registrar to prevent client validation failures.
You must also choose a denial-of-existence type: NSEC or NSEC3. NSEC3 is the default and offers limited protection against "zone walking" attacks that try to enumerate all zone records, but it produces slightly larger responses than NSEC. For NSEC3, Cloud DNS uses fixed parameters: opt-out disabled, one additional hash iteration, and a 64-bit salt.
Integrating self-hosted DNS involves configuring how Cloud DNS interacts with external DNS servers, such as those in on-premises data centers or other clouds.
Cloud DNS outbound server policies let VPC networks forward queries to external name servers. When forwarding to on-premises servers, queries come from the IP range 35.199.192.0/19 and travel through Cloud VPN tunnels or Cloud Interconnect. Firewalls on-premises must allow traffic from this range on port 53 (TCP and UDP). The on-premises network must send return traffic back to the same source IP range, and Cloud Routers must advertise 35.199.192.0/19 to on-premises BGP peers.
A DNS server policy is a rule applied at the VPC network level that controls how DNS queries from that network are handled. An outbound forwarding policy redirects queries for specific domains to alternative name servers you choose. A DNS64 policy creates IPv6 records from IPv4 records for networks with IPv6-only clients, letting them communicate with IPv4-only services.
Split-horizon DNS is the practice of providing different DNS answers to the same query depending on where the query originates, typically using separate public and private zones for the same domain.
A public zone is used for records that need to be resolved from the internet, such as a public website. It is accessible globally.
A private zone is bound to specific VPC networks and contains records for internal services, like database.internal. Only resources within those VPCs can resolve these names, keeping internal infrastructure hidden.
To implement split-horizon DNS, you create two separate managed zones in Cloud DNS with the same domain name: one public and one private. The public zone contains records for public-facing services (e.g., A record for www.example.com pointing to a public IP). The private zone contains records for internal services (e.g., an A record for www.example.com pointing to a private IP). Queries from the internet resolve using the public zone, while queries from within the authorized VPCs resolve using the private zone, providing different answers for the same domain name.
These features enable DNS resolution across separate Google Cloud projects and VPC networks without merging the networks.
In a Shared VPC environment, cross-project binding allows a service project to create its own private DNS zone and bind 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. Resources in any project attached to the Shared VPC can resolve records from these bound zones.
DNS peering enables two-way name resolution between private zones in different VPC projects. You create a peering zone in a consumer VPC that forwards lookups for a specific namespace to a producer VPC where the actual records exist. This lets services resolve internal endpoints across projects without exposing records publicly. If the producer network hosting the private zone is deleted, the peering connection breaks and dependent queries fail.
This involves integrating Cloud DNS with Google Kubernetes Engine (GKE) to automatically manage DNS records for Kubernetes services.
You can create a private DNS zone that is visible only to pods within a specific GKE cluster. This is a GKE cluster-scoped zone. You create it using gcloud dns managed-zones create with the --visibility=private flag and specify the cluster's resource path. Binding a zone to a cluster requires the dns.gkeClusters.bindPrivateDNSZone permission. DNS resolution checks the cluster scope first before broader scopes like the VPC.
The external-dns operator is a Kubernetes add-on that automatically creates and manages DNS records in Cloud DNS based on Kubernetes resources like Ingresses or Services. When configured, it watches for new Kubernetes resources and creates corresponding A or CNAME records in a designated Cloud DNS zone, ensuring that services are discoverable via DNS as they are deployed.
Both 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.
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 or, if geofencing is enabled, continue to return the IPs for the nearest region even if they are unhealthy.
Only a regional external Application Load Balancer can serve as the backup load balancer in a Cloud DNS failover policy. It can back up a global external Application Load Balancer, a classic Application Load Balancer, or another regional external Application Load Balancer.
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts