Logging and monitoring

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

Private DNS logging

Private DNS logging tracks queries that are resolved by name servers for your Virtual Private Cloud networks. Queries from an external entity directly to a public zone are not logged because they are handled by a public name server.

Logged queries can come from Compute Engine virtual machines, Google Kubernetes Engine containers in the same VPC network or peering zones, or they can come from on-premises clients via inbound DNS forwarding. The queries might eventually be resolved by private DNS zones, forwarding DNS zones, alternate name server, internal GCP DNS zones, or external DNS zones.

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 since the host project owns the network.

Enabling and disabling logging

Use DNS policies to enable logging for your networks.

Enable logging for a network that does not have a DNS policy

gcloud dns policies create [POLICY] \
    --networks=[NETWORK] \
    --enable-logging \
    --description=[DESCRIPTION]

where

  • --networks is one or more networks in a comma-separated list.

Enable logging for a network that has an existing DNS policy

gcloud dns policies update [POLICY] \
    --networks=[NETWORK] \
    --enable-logging

where

  • --networks is one or more networks in a comma-separated list.

Disable logging

This turns off logging while leaving the policy in place. Alternatively, you can delete the policy entirely.

gcloud dns policies update mypolicy \
    --networks=[NETWORK] \
    --no-enable-logging

where

  • --networks is one or more networks in a comma-separated list.

Viewing logs

Go to the Cloud DNS logs viewer page in the Google Cloud Platform Console.
Go to the Logs Viewer page

Record Format

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
source_type String Source of the query: 'inbound-forwarding', 'gce-vm' Yes
location String GCP region e.g. 'us-east1' from which the response was served. Yes
project_id String GCP 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; e.g. 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
sourceIP String / Source IP originating the query No
destinationIP String / Target Target IP, only applicable for forwarding cases. No
protocol String / DNS 'TCP' | 'UDP' 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

Monitoring metrics

Cloud DNS exports monitoring metrics to Stackdriver.

You can monitor the rate of DNS queries and responses targeting private zones, forwarding zones, policy forwarding, internal GCP zones, and the Internet. The monitoring is available in Stackdriver Monitoring and the Monitoring API.

Metrics and resource types

Private DNS exports the dns.googleapis.com/query/response_count delta metric containing the response_code label in order 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. Refer to the IANA DNS RCODEs for definitions of these codes.

The metric is exported under the dns_query resource type using the applicable fields of the log record format.

Monitoring DNS propagation

When you make changes by using the command-line tool or REST API, they are initially marked as pending until the operation has completed. You can check on the status of changes or get a history of changes by using the gcloud command-line tool or the REST API.

An operation is completed (status: done) when Cloud DNS has successfully updated the system that controls the servers. There may still be delays before all name servers are updated.

Listing changes for a managed zone

Command line

gcloud dns record-sets changes list --zone="myzonename"

Python

def list_changes(project_id, zone_name):
    client = dns.Client(project=project_id)
    zone = client.zone(zone_name)

    changes = zone.list_changes()

    return [(change.started, change.status) for change in changes]

Verifying DNS propagation

You can use the watch and dig commands to monitor and verify that your changes have been picked up by the DNS name server. The following example demonstrates looking up your name server and checking to see when a change to an MX record is picked up by one of your managed zone's name servers.

Look up your zone's name servers:

gcloud dns managed-zones describe [ZONE_NAME]

Check if the records are available yet on your authoritative name server. Replace [YOUR_ZONE_NAMESERVER] with one of the name servers from the managed zone:

watch dig example.com in MX @[YOUR_ZONE_NAMESERVER]

The watch command will run the dig command every 2 seconds by default. You can use this command 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 will wait until the previous TTL value for the record expires.

You can remove the @<address> from the dig command to run dig against your system's name server or you can change the address to other name servers if you would like to monitor propagation to other name servers.

Next steps

Was this page helpful? Let us know how we did:

Send feedback about...

Cloud DNS Documentation