Use logging and monitoring

This page provides information about logging and monitoring metrics for Cloud DNS including public zones, private zones, and forwarding zones. This page also provides instructions for monitoring the propagation of your public DNS changes.

Use Cloud DNS logging

Cloud DNS logging tracks queries that name servers resolve for your Virtual Private Cloud (VPC) networks, as well as queries from an external entity directly to a public zone.

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 Google Cloud DNS zones, or external DNS zones might eventually resolve the queries.

Log records belong to the project that owns the network or public zone 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.

Note: Cloud DNS might respond to queries using cached responses. By default, cached responses are not logged. However, if logging is enabled, at least one prior response is logged before any subsequent cached response is served without logging.

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, run the dns policies create command.

gcloud

gcloud dns policies create POLICY_NAME \
    --networks=NETWORK \
    --enable-logging \
    --description=DESCRIPTION

Replace the following:

• POLICY_NAME: the name of the DNS policy
• NETWORK: one or more networks in a comma-separated list
• DESCRIPTION: a description of the policy

To enable logging for a network that has an existing DNS policy, run the dns policies update command.

gcloud

gcloud dns policies update POLICY_NAME \
    --networks=NETWORK \
    --enable-logging

Replace the following:

• POLICY_NAME: the name of the DNS policy
• NETWORK: one or more networks in a comma-separated list

To turn off logging while leaving the policy in place, run the dns policies update command.

gcloud

gcloud dns policies update POLICY_NAME \
    --networks=NETWORK \
    --no-enable-logging

Replace the following:

• POLICY_NAME: the name of the DNS policy
• NETWORK: one or more networks in a comma-separated list

To delete the policy entirely, run the dns policies delete command.

gcloud

gcloud dns policies delete POLICY_NAME \

Replace POLICY_NAME with the name of the DNS policy that you want to delete.

Enable and disable logging for managed public zones

To turn on logging for an existing managed public zone, run the dns managed-zones update command.

gcloud

gcloud dns managed-zones update ZONE_NAME --log-dns-queries \

Replace ZONE_NAME with the name of the DNS managed zone that you want to enable logging for.

To turn off logging for an existing public managed zone, run the dns managed-zones update command.

gcloud

gcloud dns managed-zones update ZONE_NAME --no-log-dns-queries \

Replace ZONE_NAME with the name of the DNS managed zone that you want to disable logging for.

View logs

Console

In the Google Cloud console, go to the Logs Explorer page.

Go to Logs Explorer

View record format fields

Every log entry has the following fields, if applicable. Some of the fields are also shared with monitoring metrics.

Field	Field type	Description	Used in metrics
alias_query_response_code (Preview)	String	The response code returned from the query to resolve the ALIAS record's canonical name.	Yes
source_type	String	Source of the query: inbound-forwarding, gce-vm	Yes
location	String	Google Cloud region, for example us-east1, from which the response was served	Yes
project_id	String	Google Cloud project ID of the network from which the query was received	Yes
target_type	String	Type of target resolving the DNS query: private-zone, forwarding-zone, forwarding-policy, peering-zone, internal, external	Yes
target_name	String	The target name, for example zone name, policy name, internal zone name, external domain name	Yes
queryName	String / DNS	DNS query name, RFC 1035 4.1.2.	No
queryType	String / DNS	DNS query type, RFC 1035 4.1.2.	No
responseCode	Number / DNS	Response code, RFC 1035 4.1.1.	No
rdata	String / DNS	DNS answer in presentation format, RFC 1035 5.1, truncated to 260 bytes	No
authAnswer	Boolean / DNS	Authoritative answer, RFC 1035	No
sourceNetwork	String / Source	Network from which the query reached our system	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	Google Cloud 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
sourceIP	String / Source	IP originating the query	No
destinationIP	String / Target	Target IP address, only applicable for forwarding cases	No
protocol	String / DNS	TCP | UDP	No
healthyIps	String	Set of IP addresses in the ResourceRecordSet that are known to be HEALTHY to Cloud DNS at the time of the query	No
unHealthyIps	String	Set of IP addresses in the ResourceRecordSet known to be UNHEALTHY to Cloud DNS at the time of the query	No
egressError	String	Egress proxy error, the actual error reported by the egress proxy as received from the on-premises DNS server This field can be used to differentiate an actual SERVFAIL returned by the on-premises DNS versus a network error encountered by the egress proxy.	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.

For information about Cloud Logging pricing, see Pricing for Google Cloud Observability: Cloud Logging.

Troubleshoot outbound forwarding

If you receive logs containing SERVFAIL that are missing certain fields such as destinationIP, egressIP, and egressError, see the related section in the Troubleshooting documentation.

Monitor metrics

Cloud DNS exports monitoring metrics to Cloud Monitoring.

You can monitor the rate of DNS queries and responses that point to private zones, forwarding zones, policy forwarding, internal Google Cloud zones, and the internet. Monitoring is available on the Google Cloud 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.

List changes for a managed zone

To list changes for a managed zone, run the dns record-sets changes list command.

gcloud

Run the dns record-sets changes list command:

gcloud dns record-sets changes list --zone=ZONE

Replace ZONE with the name of the managed zone whose record sets you want to manage.

Verify DNS propagation

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.

Note: The commands watch and dig are provided by the Linux operating system and are not gcloud commands. As such, they don't require the gcloud prefix to run. For other operating systems, you might have to install the commands.

To look up your zone's name servers, run the dns managed-zones describe command:

gcloud dns managed-zones describe ZONE_NAME

Replace ZONE_NAME with the name of your Cloud DNS zone.

To check if the records are available yet on your authoritative name server, run the following dig command:

watch dig example.com in MX @ZONE_NAME_SERVER

Replace ZONE_NAME_SERVER with one of the name servers from the managed zone.

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.

What's next

• To add, delete, and update records, see Add, modify, and delete records.
• To create, update, list, and delete managed zones, see Managing zones.
• To find solutions for common issues that you might encounter when using Cloud DNS, see Troubleshooting.
• To reference the API, see Cloud DNS REST API.
• To get an overview of Cloud DNS, see Cloud DNS overview.