This page provides information about logging and monitoring metrics for
Cloud DNS including
private zones and
forwarding zones.
Use Cloud DNS logging
Cloud DNS logging tracks queries that name servers resolve for your
Virtual Private Cloud (VPC) networks.
Logged queries can come from Compute Engine virtual machine (VM) instances,
Google Kubernetes Engine containers in the same VPC network,
peering zones, or
on-premises clients that use inbound DNS
forwarding.
Private DNS zones, forwarding DNS zones, alternative name servers, internal
Cloud de Confiance DNS zones, or external DNS zones might eventually resolve
the queries.
Log records belong to the project that owns the network that
carried the request. In the case of Shared VPC,
the log records belong to the host project because the host project owns the
network.
Enable and disable logging for private managed zones
Use DNS policies to enable or disable logging for your networks. When you enable
query logging, every DNS query to a Cloud DNS private
managed zone is logged.
To enable logging for a network that does not have a DNS policy, complete the
following steps.
Source of the query: inbound-forwarding, gce-vm, internet, peering-zone, fqdn-forwarding-target
No
target_name
String
The target name, for example zone name, policy name, internal zone name,
external domain name
Yes
target_type
String
Type of target resolving the DNS query: private-zone, forwarding-zone,
forwarding-policy, peering-zone, internal, external,
response-policy, service-directory-zone, reverse-lookup-zone,
zonal-private-zone
Yes
unHealthyIps
String
Set of IP addresses in the ResourceRecordSet known to be
UNHEALTHY to Cloud DNS at the time of the query
No
vmInstanceId
Number / Source
Compute Engine VM instance ID, only applicable to queries
initiated by Compute Engine VMs
No
vmInstanceName
String / Source
Compute Engine VM instance name, only applicable to queries
initiated by Compute Engine VMs
No
vmProjectId
String / Source
Cloud de Confiance project ID of the network from which the query was sent,
only applicable to queries initiated by Compute Engine VMs
No
vmZoneName
String / Source
Name of the VM zone from which the query was sent, only applicable to
queries initiated by Compute Engine VMs
No
Pricing
All Cloud DNS logs are written to Cloud Logging. There is no
separate charge from Cloud DNS for this service. However, these logs
can result in additional storage costs depending on the size of the logs that are
written and stored.
For calculation purposes, Cloud DNS writes approximately 5 MB of log
data for processing 10,000 DNS queries.
You can monitor the rate of DNS queries and responses that point to private
zones, forwarding zones, policy forwarding, internal Cloud de Confiance zones,
and the internet. Monitoring is available on the Cloud de Confiance console
Monitoring page
and in the
Cloud Monitoring API.
Private DNS exports the dns.googleapis.com/query/response_count delta metric
that contains the response_code label to count the number of queries per
response code.
The response_code label is of type string with the possible values of
NOERROR, FORMERR, SERVFAIL, NXDOMAIN, NOTIMP, and UNKNOWN.
For definitions of these codes, see the
IANA DNS RCODEs.
The metric is exported under the dns_query resource type by using the
applicable fields of the log
record format.
Monitor DNS propagation
When you use the Google Cloud CLI or the REST API to make changes, the changes are
initially marked as pending until the operation is completed. You can
use the gcloud CLI or the REST API to check on the status of changes
or get a history of changes.
An operation is completed (status: done) when Cloud DNS has
successfully updated the system that controls the servers. There might still
be delays before all name servers are updated.
To monitor and verify that the DNS name server has picked up your changes, you
can use the watch and dig commands. The following example demonstrates how
to look up your name server and check to see when one of your managed zone's
name servers has picked up a change to an MX record.
To look up your zone's name servers, complete the following steps.
The watch command runs the dig command every 2 seconds by default. You
can use this command to determine when your authoritative name server picks up
your change, which should happen within 120 seconds. After your authoritative
name server has the change, DNS resolvers can start to pick up the new record.
Resolvers that already have the previous record cached wait for the
previous TTL value of the record to expire.
To run dig against your system's name server, you can remove the @<address>
from the dig command. If you would like to monitor propagation to other name
servers, you can change the address to point to other name servers.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2026-07-07 UTC."],[],[]]
