Professional Cloud Network Engineer
Identity and Access Management (IAM) controls who can view or modify Cloud DNS resources using predefined roles. The Managed DNS Project Viewer role lets users see DNS zones and records without making changes, while the Managed DNS Project Admin role lets users create and update zones and records. When running service meshes with compute instances, clients like Envoy proxies authenticate using the Cloud Service Mesh Client role, which includes permissions for getting network configs and reporting metrics. Security teams should separate Google Workspace administrators from cloud administrators using custom roles, keep domain names separate across different accounts to avoid conflicts, and protect public DNS zones where MX and verification records live to prevent unauthorized administrative takeover.
Cloud DNS outbound server policies let VPC networks forward queries to external and on-premises name servers across hybrid connections. When forwarding to on-premises name servers, Cloud DNS sends queries from the IP range 35.199.192.0/19, and packets travel through Cloud VPN tunnels, Cloud Interconnect VLAN attachments, or Cloud Router dynamic routes. Firewalls on the on-premises side must allow traffic from 35.199.192.0/19 on port 53 (TCP and UDP), and the on-premises network must send return traffic back to that same IP range. Cloud Routers must advertise 35.199.192.0/19 to on-premises BGP peers using custom route advertisements, and response packets must keep the same source IP that the original query used or Cloud DNS will drop the response.
DNS peering zones let different VPC networks resolve names without exposing resources publicly. A peering zone lives in a consumer VPC and forwards lookups for a specific namespace to a producer VPC where the actual records exist, which lets services like Apigee resolve internal endpoints across projects. Organizations can redirect Google service requests to the restricted VIP range 199.36.153.4/30 by creating private managed zones for domains like pkg.dev and gcr.io with CNAME records. Egress firewall rules must allow TCP traffic to port 443 on the 199.36.153.4/30 subnet. If the producer network hosting a private DNS zone is deleted, the peering connection breaks and dependent queries fail.
Private Service Connect (PSC) DNS automation creates and manages DNS records automatically in consumer VPC networks. When enabled on services like Cloud SQL, the system automatically generates universal DNS records pointing to the assigned endpoint IP address across all authorized consumer projects and networks. Deploying Cloud SQL Enterprise Plus instances with write endpoint DNS automation creates a global cluster write endpoint that always resolves to the current primary instance IP address. When database failover happens, the global write record updates automatically, so applications can keep writing to the database without manual connection updates or restarts.
Access to Cloud DNS resources is controlled by IAM roles that determine what actions users can perform. The DNS Administrator role gives full read-write access to all Cloud DNS resources, including creating and deleting managed zones and policies, while the DNS Reader role provides read-only access. A specialized DNS Peer role grants only one permission called dns.networks.targetWithPeeringZone, which is required for setting up DNS peering zones. The Cloud DNS Service Agent role is reserved for Google's own service agents and should never be given to users. Key permissions for managing records include creating, updating, and deleting resource record sets.
A managed zone is a container that holds all DNS records for the same domain suffix, and private zones limit who can see those records. Cloud DNS uses scopes to define where a private DNS resource is visible and resolvable, with two main types: VPC scope and GKE cluster scope. A VPC-scoped zone is visible to everything inside one Virtual Private Cloud network, while a GKE cluster-scoped zone is visible only to pods within a specific Google Kubernetes Engine cluster. DNS resolution checks the most specific scope first, like a cluster, before moving to broader scopes like the VPC.
To create a private DNS zone that works only within a GKE cluster, you use the gcloud dns managed-zones create command with the --visibility=private flag and specify the cluster's full resource path. To add a cluster to an existing private zone, you use gcloud dns managed-zones update with the --gkeclusters= flag. Both operations require the dns.gkeClusters.bindPrivateDNSZone permission, which comes with the DNS Administrator role. Once bound, pods in that specific cluster can resolve records in the zone.
DNS server policies are rules applied at the VPC network level that control how DNS queries from that network are handled. An outbound forwarding policy redirects queries for specific domains to alternative name servers you choose, which helps in hybrid cloud situations where you need to resolve on-premises names. A DNS64 policy creates IPv6 records from IPv4 records for networks with IPv6-only clients, letting them communicate with IPv4-only services. You create policies with the gcloud dns policies create command and attach them to one or more VPC networks.
You manage DNS server policies using gcloud commands like create, update, list, describe, and delete. When updating a policy, you can change which VPC networks it applies to or turn inbound query forwarding on or off. Resource records like A, AAAA, CNAME, MX, and TXT are managed within a zone by specifying the DNS name, record type, and the data like an IP address. For complex routing situations, you configure routing policies such as weighted, geographic, or failover within a record set to direct traffic based on health, location, or defined weights.
Before moving DNS zones to Cloud DNS, you must check that all existing DNS records will work correctly in the new system. This means exporting current zone files from the source DNS server, confirming all record types are present, and making sure TTL values fit the migration timeline. In hybrid environments where on-premises DNS handles internal resolution and Cloud DNS handles Google Cloud names, you must verify that DNS forwarding works both directions between on-premises and VPC networks, and that firewalls allow DNS traffic on port 53. If you use a Shared VPC where different service projects manage their own resources, you should set up cross-project binding of DNS zones so namespace delegation works properly.
The cutover method decides how and when DNS resolution switches from the old provider to Cloud DNS, and the choice depends on how much downtime your organization can tolerate. A big bang cutover updates the parent zone's nameserver records all at once, which gives a clean switch but means any mistake in Cloud DNS causes complete resolution failures. A phased cutover uses forwarding rules or weighted routing to gradually shift traffic, letting you test Cloud DNS with some queries before switching everything over. Cloud DNS supports weighted round robin routing that lets you send a percentage of traffic to different targets, which helps test the migrated zone while the old provider still serves production traffic. For GKE clusters moving from kube-dns to Cloud DNS, the migration happens at the control plane level and requires recreating nodes because existing nodes keep pointing to the kube-dns IP address.
After switching to Cloud DNS, you must confirm that DNS resolution works for all record types from every network that will query the zones. This means testing from on-premises networks, from VPC networks in Google Cloud, and from external internet clients for public zones, while also confirming that forwarding between environments still works. In hybrid DNS designs where external networks communicate through Google Cloud to other external networks, you must ensure external DNS zones forward requests directly to each other and that firewall rules allow DNS traffic between external networks. For zones with CNAME records, verify that Cloud DNS chases CNAMEs correctly based on zone type: private zones chase CNAMEs within authorized VPCs but not in public zones, forwarding zones don't chase CNAMEs from target servers, and public zones chase CNAMEs in both internal and public zones.
A VPC-scoped private zone is visible to all resources within a single Virtual Private Cloud network, while a GKE cluster-scoped zone is visible only to pods inside one specific Google Kubernetes Engine cluster. The cluster scope provides stronger isolation for applications that should not be reachable from other parts of the network.
Choose a big bang cutover when you need a clean break and can tolerate no resolution during the switch, because any misconfiguration causes immediate failure. Choose a phased cutover when you need to test Cloud DNS gradually while the old provider still serves production traffic, using weighted routing to send a portion of queries to the new system.
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts