Securing Cloud DNS with DNSSEC and Private Zones

Implement and Manage DNSSEC for Managed Public Zones means turning on cryptographic signing for a public managed zone so validating resolvers can reject forged answers. Cloud DNS (opens in a new tab) signs the zone with a Key Signing Key (KSK) and Zone Signing Key (ZSK), and the parent zone learns to trust those signatures through Delegation Signer (DS) records published at the registrar. Only when signing, key management, and DS publication are all complete can resolvers validate responses end to end and block spoofing and cache poisoning.

1.1Why DNS Zone Integrity Is Perimeter Protection

DNS zone integrity is perimeter protection because Cloud Identity (opens in a new tab) and Google Workspace accounts are identified by a primary DNS domain name. Ownership of that domain is proven by creating a special DNS record in the zone, and daily operations continue to depend on the same zone for mail flow and account recovery. An attacker who can modify MX records can reroute email to a different server and read sensitive messages. An attacker who can add records can complete a super admin password reset and take over the account. Because DNS controls both mail routing and recovery, the DNS server for the primary domain must be treated as a security boundary.

1.2Select a DNS Provider for Signed Domains

DNS provider selection decides where authoritative records and DNSSEC settings live. When a domain is registered through Cloud Domains, the DNS provider and DNSSEC options can be changed through Edit DNS details. The registration exposes dsState, such as DS_RECORDS_UNPUBLISHED, which shows whether DS records have been published at the registrar to complete the chain of trust.

Choose Cloud DNS when the zone needs Google-managed signing and centralized administration with Identity and Access Management (IAM). Choose custom name servers only when records and signing must stay with a third-party provider.

1.3Enable DNSSEC on Cloud DNS Managed Public Zones

Enabling DNSSEC on a Cloud DNS managed public zone turns on cryptographic signing for that zone so validating resolvers reject forged responses. Security Command Center (opens in a new tab) tracks this posture with the compliance control for enabling DNSSEC for Cloud DNS. The zone, the name servers, and the registration must be connected in order. First, the public managed zone is created and serves the authoritative records. Then, the domain registration is pointed to the Cloud DNS name servers or managed zone name. Only after the registrar publishes the DS records does trust extend from the parent zone to the signed child zone.

1.4Control Administrative Access to Signed Zones

Administrative access to signed zones is controlled with least privilege because any zone administrator can change signed records, MX routing, and verification records. Viewing zones and records uses a viewer role, while creating and updating zones and records requires a separate elevated admin role. Keep the number of DNS administrators for the primary identity domain as small as the number of super admins. Use pre-built or custom administrator roles instead of full super admin rights where possible, and audit administrative activity to detect suspicious changes. This containment keeps an unauthorized zone change from bypassing DNSSEC signing.

Secure private DNS zones are Cloud DNS (opens in a new tab) private managed zones whose names resolve only inside authorized Virtual Private Cloud (VPC) networks and explicitly peered environments. A private zone keeps internal hostnames off the public internet, while cross-VPC DNS peering extends that controlled resolution to another VPC without publishing the records. Granular IAM permissions, response policies, and health-checked routing then decide who can change records, which malicious domains are blocked, and which healthy endpoint answers.

2.1Private Managed Zones and Visibility Boundaries

Cloud DNS private managed zones are authoritative zones that are private to the VPC networks authorized to see them. By default, a workload outside an authorized VPC cannot resolve names in the private zone, even if it knows the fully qualified domain name. This boundary places internal resolution on one side and public internet DNS on the other, so internal service names, backend targets, and static private endpoints stay hidden from external resolvers. A common pattern is to hold private target endpoints in one private zone in a Google Cloud project and then authorize or peer only the VPCs that need those names.

2.2Granular IAM Permissions for DNS Zones and Records

Granular IAM permissions for Cloud DNS enforce least privilege over viewing versus changing zones and records. A role is a collection of permissions mapped to actions on resources and assigned to users, groups, or service accounts. The Managed DNS Project Viewer (managed-dns-project-viewer) role views existing zones and records, while the Managed DNS Project Admin (managed-dns-project-admin) role creates and updates zones and records. Platform administrators and application operators must hold the correct role before managing managed DNS services, and access to the DNS server for the primary identity domain must be limited to people trusted at the super admin level.

2.3Cross-VPC DNS Peering Between Consumer and Producer Networks

Cross-VPC DNS peering uses a peering zone to send DNS requests between Cloud DNS zones in different VPC networks. An administrator creates a Cloud DNS private peering zone and configures it to perform lookups in the VPC network where the records for that namespace live. The VPC network that holds the authoritative records is the DNS producer network. Queries originate on the consumer side, and data flows from the consumer VPC to the peering zone and then to the producer VPC for authoritative lookup. Resolution depends on the target network remaining present, so if the target network is deleted, all matching queries through the peering zone fail.

Both patterns preserve the private visibility boundary because only the explicitly peered consumer can resolve the producer namespace. Choose the shared-zone pattern when VPC peering already connects the networks, and choose the forwarding peering-zone pattern when no VPC peering exists but controlled private resolution is still required.

2.4DNS Peering for Private Services Access

DNS peering for private services access lets workloads in a VPC resolve service-producer domain names without using public DNS. These supported private services access (opens in a new tab) services support DNS peering, with the exception of Cloud SQL, and the project must have the Cloud DNS API (dns.googleapis.com) enabled before peering can be configured. To set up peering, the administrator creates a peered DNS domain that binds a VPC network to a DNS suffix in the service producer network. Traffic then flows from workloads in the VPC network to the producer network for those suffixes. The DNS suffix must be a complete domain name including the trailing dot, for example example.com..

Hybrid use adds a routing dependency. By default the service producer network only learns subnet routes from the VPC network, so requests that are not from a subnet IP range are dropped by the producer. The VPC network must therefore export eligible custom routes, such as routes to an on-premises network, so the producer imports them and can return traffic through the VPC. Exported routes that overlap Private Google Access ranges can misroute producer traffic intended for Google services, so administrators must avoid overlapping exports or enable VPC Service Controls on the private services access connection to enforce perimeter routing for Google services.

2.5Hardening Identity-Linked DNS Against Hijacking and Takeover

Identity-linked DNS zones are the zones that hold the primary domain used for Cloud Identity (opens in a new tab) or Google Workspace, starting with domain-ownership verification through a special DNS record. Those zones stay security-critical because Google Workspace relies on MX records for email routing, so changing MX records can redirect mail to an attacker server. An attacker able to add records may also complete a super admin password reset and gain control of the account and its Google Cloud organization. To prevent takeover, limit administrative access to that DNS server, use disjoint domains across separate identity accounts to avoid subdomain verification conflicts, and treat any DNS administrator as fully trusted.

Enforcing DNS server policies and security logging across hybrid networks means controlling how names resolve between Google Cloud VPCs and on-premises environments and recording that activity for detection. In Cloud DNS (opens in a new tab), a managed private zone provides internal resolution inside a Virtual Private Cloud (VPC), DNS peering extends specific suffixes to another network, and hybrid connectivity over Cloud VPN or Dedicated and Partner Interconnect carries the queries. Inbound and outbound DNS server policies govern the direction of hybrid lookups, alternative name servers provide the next hop, and query logging supports detection of anomalous patterns such as domain generation algorithm (DGA) traffic.

3.1Govern Hybrid Resolution with Private Zones and Peering

Cloud DNS hybrid resolution starts with enabling the Cloud DNS API and creating a managed private zone for the VPC. Queries from Compute Engine, Google Kubernetes Engine, and Cloud Service Mesh data-plane clients flow from the VPC resolver to the private zone first, and only matching names are answered privately before public resolution is attempted. To enable the API:

1. Open the API Library: Go to the API Library page for the project in the Google Cloud console.
2. Search for DNS: Enter DNS in the Search for APIs and Services field.
3. Select Cloud DNS API: Click Cloud DNS API in the results list.
4. Enable: Click Enable on the Cloud DNS API page, or run gcloud services enable dns.googleapis.com.

DNS peering extends resolution to another network without exposing zones publicly. A peering configuration binds a VPC network to a DNS suffix in a producer or peer network, so queries for that suffix flow from the VPC resolver to the peer name servers. The suffix must be a complete domain name including the trailing dot, for example example.com..

3.2Connect On-Premises Name Servers Without Leaking Routes

Hybrid name resolution between a VPC network and on-premises hosts depends on both DNS forwarding and network routes. On-premises DNS records can be configured to resolve selected Google API domains to the internal IP address of a Private Service Connect endpoint, so traffic from the data center to Google services stays on private connectivity. In the VPC network, the peering connection must export custom routes to the service producer network so return traffic can flow back through the VPC to on-premises.

Exporting routes requires care because the producer network automatically imports eligible static and dynamic routes from the VPC network. If exported custom routes overlap with ranges used for Private Google Access, traffic from the producer intended for Google services can be misrouted over the peering connection. To prevent that conflict, avoid exporting overlapping ranges or enable VPC Service Controls for the private services access (opens in a new tab) connection to enforce perimeter routing for Google services inside the perimeter.

3.3Secure Administrative Access to DNS Zones

Secure access to DNS zones protects identity and mail routing for Cloud Identity (opens in a new tab) and Google Workspace accounts. Each account is identified by a primary DNS domain that must be verified by creating a special DNS record, which proves ownership of the zone. After verification, DNS remains critical because MX records control email routing and added records can enable password resets for highly privileged users. An attacker who can modify MX records can reroute email to a different server and gain access to sensitive information. An attacker who can add records can hijack verification flows and reset a super admin password to take over the account. Protection therefore treats DNS administration as equivalent to super admin access by limiting the number of users with administrative access to the DNS server for the primary domain.

3.4Isolate Namespaces with Disjoint Domains

Disjoint DNS domains prevent name conflicts between separate Cloud Identity or Google Workspace accounts used for staging and production. When example.com is added and verified, subdomains such as marketing.example.com and finance.example.com can be added without separate verification. That inheritance creates risk when another account already uses one of those subdomains. The secure pattern is to use two domains that are not subdomains of each other for the two accounts, including primary and secondary domains. When Active Directory or Microsoft Entra ID federation is used, the same mapping approach for DNS domains, users, and groups is applied to both the staging tenant and account pair and the production tenant and account pair. If forest or tenant domain names do not allow the same mapping, register additional User Principal Name suffix domains or add an extra domain to the staging tenant.

3.5Enable IAM Control and Query Visibility for Detection

Visibility for DNS security comes from combining least-privilege IAM with centralized logging and traffic inspection. Identity and Access Management (IAM) for managed DNS separates viewing from change rights, with the Managed DNS Project Viewer role for viewing zones and records and the Managed DNS Project Admin role for creating and updating them. Auditing of administrative actions can be exported to BigQuery to detect suspicious activity among administrators. Network-level visibility inspects inbound and outbound communication by default. Firewalls enforce default-deny as the initial posture to prevent unintentional access and leakage, while Intrusion Detection and Prevention inspects traffic, analyzes it, and blocks unauthorized entry. Both firewall and Intrusion Detection and Prevention telemetry integrates with the organization Observability stack for workload analysis and with the security information and event management stack for infrastructure forensics, which allows teams to correlate anomalous query patterns with broader compromise indicators.

Key Facts

• DNSSEC on a Cloud DNS public managed zone adds cryptographic signatures using a Key Signing Key and Zone Signing Key, and trust is completed only after Delegation Signer records are published at the registrar.
• The DNS server for the primary Cloud Identity or Google Workspace domain controls MX mail routing and super admin recovery, so its administrators must be trusted at the super admin level.
• Cloud DNS private managed zones resolve only inside authorized VPC networks, and cross-VPC DNS peering lets a consumer VPC forward lookups for a specific namespace to a producer VPC without exposing records publicly.
• DNS peering suffixes must be complete domain names with a trailing dot, such as example.com., and private services DNS peering does not apply to Cloud SQL.
• Managed DNS Project Viewer views zones and records while Managed DNS Project Admin creates and updates them, and administrative auditing can be exported to BigQuery for detection.