Professional Cloud Security Engineer
Prepare and test your skills
Prepare and test your skills
DNSSEC is a security extension that adds cryptographic signatures to DNS records. Enabling it on a public managed zone in Cloud DNS prevents attackers from spoofing responses or poisoning caches, which could redirect users to malicious sites. This establishes a chain of trust for DNS queries.
When you enable DNSSEC in Cloud DNS, it generates two types of cryptographic keys. The Key Signing Key (KSK) signs the zone's DNSKEY records, while the Zone Signing Key (ZSK) signs all other DNS records. You must choose a signing algorithm, like RSASHA256, based on your security needs. To complete the setup, you submit the generated Delegation Signer (DS) record to your domain registrar. Publishing this record in the parent zone (like .com) allows external DNS resolvers to verify your zone's signatures are authentic.
Maintaining security requires regular key rotation. Cloud DNS can automate ZSK rotations, but KSK rotations often require you to manually update the DS record with your registrar. For high-security needs, you can configure custom key-signing policies, such as specific key lifetimes. Monitoring DNSSEC status through logs ensures signatures remain valid, protecting your network perimeter from DNS-based attacks.

A five-step process flow showing how enabling DNSSEC on a Cloud DNS public managed zone generates the KSK and ZSK keys, signs the zone's records, publishes the DS record via the registrar into the parent .com zone, and lets external resolvers verify signatures, completing the chain of trust. A pulse travels step by step along the flow as each stage highlights in order.
Securing name resolution in environments that mix Google Cloud VPCs and on-premises networks involves controlling query flow and monitoring for threats. Cloud DNS provides policies to govern this hybrid traffic and logging to detect malicious activity.
Outbound server policies direct DNS queries from Cloud DNS to specific alternative name servers. You have three main types: using default Google DNS, routing to on-premises servers via the 35.199.192.0/19 IP range, or using Google Public DNS for internet queries. For the on-premises option, your firewall must allow traffic from that IP range on port 53. Inbound server policies work in the opposite direction, allowing on-premises servers to resolve records hosted in Cloud DNS. This requires configuring routes, often with Cloud Router, to ensure traffic flows correctly between the networks.
Cloud DNS query logging, integrated with Cloud Logging, captures details like source IPs and queried domains. Analyzing these logs is critical for identifying anomalous patterns, such as traffic from domain generation algorithms (DGA) used by malware to contact command-and-control servers. This visibility helps security teams detect compromised systems. Implementing IAM roles with least privilege and using VPC Service Controls further secures the DNS service from unauthorized access and data exfiltration.
Private managed zones in Cloud DNS provide internal name resolution without exposing records to the internet, reducing the attack surface. These zones are essential for services like private Google APIs and container registries, keeping traffic within trusted network boundaries.
DNS peering zones enable cross-VPC resolution, allowing a consumer VPC to query records hosted in a producer network. This is managed alongside DNS server policies, which define custom forwarding behaviors. For hybrid connectivity, outbound policies forward queries to on-premises servers using the 35.199.192.0/19 range, and inbound policies create entry points for external networks to query private zones. The on-premises firewall must be configured to allow traffic from this specific range and route responses back correctly to prevent spoofing.
Applying granular IAM permissions is vital to prevent unauthorized record manipulation, which could lead to credential theft or perimeter compromise. Roles like DNS Project Admin or the specialized roles/dns.peer should be granted following the principle of least privilege. To actively block threats, you can use Cloud DNS response policies. These policies let you intercept and override queries within the VPC, blocking connections to known malicious domains and preventing data exfiltration. Combining this with health-checked routing ensures traffic is only sent to healthy backend instances, creating a resilient and secure resolution architecture.
In Cloud DNS, the Key Signing Key (KSK) signs the zone's DNSKEY records, while the Zone Signing Key (ZSK) signs all other DNS records. Cloud DNS can automate ZSK rotations, but KSK rotations often require administrators to manually update the Delegation Signer (DS) record with their domain registrar.
The on-premises firewall must permit incoming traffic from the 35.199.192.0/19 IP range on port 53 and ensure responses route back correctly to prevent spoofing. This configuration allows Cloud DNS outbound server policies to successfully route DNS queries to on-premises name servers.
Cloud DNS response policies protect resources by intercepting and overriding DNS queries executed within the VPC. This capability allows administrators to block connections to known malicious domains and prevent data exfiltration.
Cloud DNS query logging captures query metadata, including source IP addresses and queried domains, and integrates with Cloud Logging to expose anomalous activity. Analyzing these logs allows security teams to identify threats such as queries produced by domain generation algorithms (DGA) attempting to reach command-and-control servers.
An enterprise maintains a hybrid architecture connecting an on-premises data center to a Google Cloud Virtual Private Cloud (VPC) over Cloud Interconnect. The organization has established the following security and networking requirements for name resolution:
Which Cloud DNS design and policy configuration should the security engineer implement to satisfy these requirements?
Deploy a Cloud Service Mesh Envoy proxy layer with auto-capacity draining to route port 53 UDP/TCP traffic across Cloud Interconnect, and configure Cloud Armor security policies on the proxies.
Configure a Packet Mirroring policy targeting an internal passthrough Network Load Balancer collector pool to inspect port 53 traffic, and configure custom iptables DNAT rules on each VM to redirect DNS queries to on-premises servers.
Create a Cloud DNS server policy attached to the VPC with inbound query forwarding enabled, configure outbound private forwarding zones to direct on-premises domain queries to the on-premises DNS servers, and enable Cloud DNS query logging on the VPC network.
Deploy a global external Application Load Balancer with Cloud DNS failover routing policies to route on-premises DNS traffic, and configure VPC Flow Logs with a 100% sample rate.