Google CloudOverview
Cloud DNS logging records the queries from the name servers within your VPC to Stackdriver. Logged queries can come from Compute Engine VMs, GKE containers, or other GCP resources provisioned within the VPC.
Rationale
Security monitoring and forensics cannot depend solely on IP addresses from VPC flow logs, especially when considering the dynamic IP usage of cloud resources, HTTP virtual host routing, and other technology that can obscure the DNS name used by a client from the IP address.
Monitoring of Cloud DNS logs provides visibility to DNS names requested by the clients within the VPC. These logs can be monitored for anomalous domain names and evaluated against threat intelligence
Note: For full capture of DNS, firewall must block egress UDP/53 (DNS) and TCP/443 (DNS over HTTPS) to prevent client from using external DNS name server for resolution.
Impact
Enabling Cloud DNS logging might result in your project being charged for additional logs usage.
Remediation guidance
From Command Line
Add New DNS Policy With Logging Enabled
For each VPC network that needs a DNS policy with logging enabled:
gcloud dns policies create enable-dns-logging --enable-logging --description="Enable DNS Logging" --networks=VPC_NETWORK_NAME
The VPC_NETWORK_NAME can be one or more networks in comma-separated list
Enable Logging for Existing DNS Policy For each VPC network that has an existing DNS policy that needs logging enabled
gcloud dns policies update POLICY_NAME --enable-logging --networks=VPC_NETWORK_NAME
The VPC_NETWORK_NAME can be one or more networks in comma-separated list
Default Value
Cloud DNS logging is disabled by default on each network.
Google Cloud Console (Asset-Level)
- Open the affected project/resource from the finding details in Google Cloud Console.
- Navigate to the resource security/configuration settings.
- Apply the control-specific secure configuration.
- Save and re-run the check.
Multiple Remediation Paths
Google Cloud
SERVICE-WIDE (RECOMMENDED when many resources are affected): Enforce Organization Policies at org/folder level so new resources inherit secure defaults.
gcloud org-policies set-policy policy.yaml
ASSET-LEVEL: Use the product-specific remediation steps above for only the impacted project/resources.
PREVENTIVE: Use org policy constraints/custom constraints and enforce checks in deployment pipelines.
References for Service-Wide Patterns
- GCP Organization Policy overview: https://cloud.google.com/resource-manager/docs/organization-policy/overview
- GCP Organization policy constraints catalog: https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints
- gcloud org-policies: https://cloud.google.com/sdk/gcloud/reference/org-policies
Operational Rollout Workflow
Use this sequence to reduce risk and avoid repeated drift.
1. Contain at Service-Wide Scope First (Recommended)
- Google Cloud: apply organization policy constraints at org/folder scope.
gcloud org-policies set-policy policy.yaml
2. Remediate Existing Affected Assets
- Execute the control-specific Console/CLI steps documented above for each flagged resource.
- Prioritize internet-exposed and production assets first.
3. Validate and Prevent Recurrence
- Re-scan after each remediation batch.
- Track exceptions with owner and expiry date.
- Add preventive checks in IaC/CI pipelines.
Query logic
These are the stored checks tied to this control.
Google Cloud VPCs without DNS logging
Connectors
Covered asset types
Expected check: eq []
{
vpcs(where: { dnsPolicy_NONE: { NOT: { enableLogging_IN: ["true"] } } }) {
...AssetFragment
}
}
