Use Cloud DNS logs to monitor DNS failure rates

Linux Windows

You can enable Cloud DNS query logs in your Compute Engine project and usethose logs to monitor and compare internal DNS failure rates before and aftermigration to zonal internal DNS. Log entries record successful DNS resolutionand when internal DNS fails to resolve a given domain name.

Overview

To use Cloud DNS query logs to monitor internal DNS failure rates, completethe following steps:

  1. Get the Virtual Private Cloud (VPC) network name for the VPCthat contains the VMs to monitor.
  2. Using the VPC network names, run a Google Cloud CLI commandto enable DNS query logging.
  3. Run queries in Logs Explorer to visualize and investigate success andfailure rates.

Pricing information for Cloud DNS query logging

When you enable Cloud DNS query logging, it generates a significant amount oflogs, many of which are not related to internal DNS. As a result, you mightincur a cost for using this feature. In general, the first 50 GiB of logstorage per project per month is free. Each additional 50 GiB costs $0.50USD.

For more information about the pricing, seeCloud Logging pricing summary.

Get the Virtual Private Cloud (VPC) network names

To capture DNS query data, you must enable logging for the VPCnetwork that is used by your compute instance. Often, a Google Cloud project hasmultiple VPC networks. You can use a gcloud CLIcommand to list the VPC networks used by the compute instancesthat you want to monitor.

Console

  1. In the Google Cloud console, go to theVM instances page.

    Go to VM instances

  2. Optional: Use theFilter box to restrict the number of instances shown.

  3. Click the name of the instance that you want to inspect.

  4. In theNetworking section, underNetwork interfaces, you can seethe network interfaces (NICs) created for the instance, the network andsubnet associated with each NIC, and their assigned IP addresses.

gcloud

  • To view the VPC networks used by all compute instances in aproject, use thegcloud compute instances list command.You can append a--format option to the command to restrict theinformation returned to specific fields and change how it is displayed,for example:

    gcloud compute instances list \  --format="flattened(name,networkInterfaces[].name, \    networkInterfaces[].network.basename(), \    networkInterfaces[].stackType, networkInterfaces[].nicType)"

    The output is similar to the following:

    name:                           test-gvnicnetworkInterfaces[0].name:      nic0networkInterfaces[0].network:   defaultnetworkInterfaces[0].nicType:   GVNICnetworkInterfaces[0].stackType: IPV4_ONLY---name:                           test-multinicnetworkInterfaces[0].name:      nic0networkInterfaces[0].network:   defaultnetworkInterfaces[0].nicType:   GVNICnetworkInterfaces[0].stackType: IPV4_ONLYnetworkInterfaces[1].name:      nic0.14networkInterfaces[1].network:   net0networkInterfaces[1].stackType: IPV4_ONLYnetworkInterfaces[2].name:      nic1networkInterfaces[2].network:   prod-ipv6networkInterfaces[2].nicType:   GVNICnetworkInterfaces[2].stackType: IPV4_IPV6

  • To view the network interfaces (NICs) for a specific compute instance andits assigned VPC networks, use thegcloud compute instances describe command.You can append a--format option to the command to restrict theinformation returned to specific fields and change how it is displayed,for example:

    gcloud compute instances describeINSTANCE_NAME --zone=ZONE \  --format="flattened(name,networkInterfaces[].name, \  networkInterfaces[].network.basename(), \  networkInterfaces[].stackType, networkInterfaces[].nicType)"

    Replace the following:

    • INSTANCE_NAME: the name of the instance to view
    • ZONE: the zone for the instance that you want toview

    The output is similar to the following:

    name:                           test-instancenetworkInterfaces[0].name:      nic0networkInterfaces[0].network:   defaultnetworkInterfaces[0].nicType:   GVNICnetworkInterfaces[0].stackType: IPV4_ONLYnetworkInterfaces[1].name:      nic1networkInterfaces[1].network:   prod-ipv6networkInterfaces[1].nicType:   GVNICnetworkInterfaces[1].stackType: IPV4_IPV6networkInterfaces[1].name:      nic1.2networkInterfaces[1].network:   alt-ipv6-netnetworkInterfaces[1].nicType:   GVNICnetworkInterfaces[1].stackType: IPV4_IPV6networkInterfaces[1].parentNicName: nic1

Enable Cloud DNS query logging

Cloud DNS logging tracks queries that name servers resolve for yourVPC networks, as well as queries from an external entity directlyto a public zone.

Logged queries can come from Compute Engine instances, Google Kubernetes Engine containersin the same VPC network, peering zones, or on-premises clientsthat use inbound DNS forwarding. Private DNS zones, forwarding DNS zones,alternative name servers, internal Google Cloud DNS zones, or external DNS zonesmight eventually resolve the queries.

Log records belong to the project that owns the network or public zone thatcarried the request. In the case of Shared VPC, the log records belongto the host project because the host project owns the network.

To enable DNS logging, do one of the following:

  • Create a new DNS policy with logging enabled by running thegcloud dns policies create command.

    gcloud dns policies createPOLICY_NAME \    --networks=NETWORK_NAMES \    --enable-logging \    --description="Enable DNS query logging forNETWORK_NAMES"

  • If the network already has DNS policy, update the existing logging policyby running thegcloud dns policies update command.

    gcloud dns policies updatePOLICY_NAME \   --networks=NETWORK_NAMES \   --enable-logging \

Replace the following:

  • POLICY_NAME: the name of the DNS policy
  • NETWORK_NAMES: a comma-separated list of network names

For detailed instructions on how to create and enable DNS policies for logging,seeUse Cloud DNS logging.

Use Logs Explorer to view the logs and visualize DNS failure rates

After you enable DNS logging, the project starts to accumulate logs inLogs Explorer. To view these logs, use the Google Cloud console and go to theLogs Explorer page.

Go to Logs Explorer

Monitor DNS name resolution failures

Use theNXDOMAIN response code to isolate non-existent domain failures. Thesefailures occur when internal DNS fails to resolve a given domain name.

  1. In the query box on theLogs Explorer console page, enter thefollowing text:

    resource.type="dns_query"jsonPayload.queryType="A"jsonPayload.queryName=~"\.internal\.$"jsonPayload.responseCode = "NXDOMAIN"

  2. ClickRun query.

Note: Some failures are normal when using non-fully qualified domain names(FQDN) for compute instances because of how the DNS resolver uses search pathsto facilitate communication.

Monitor successful name resolution queries

Use theNOERROR response code to isolate successful DNS resolution.

  1. In the query box on theLogs Explorer console page, enter thefollowing text:

    resource.type="dns_query"jsonPayload.queryType="A"jsonPayload.queryName=~"\.internal\.$"jsonPayload.responseCode = "NOERROR"

  2. ClickRun query.

Establish an analysis timeframe

You can use the logs time range selector to change the timeframe for theanalyzed logs. This selector is found in the top right corner of theLogs Explorer window.

For an effective comparison of error and success rates you must enable DNSquery logs prior to migrating to using zonal DNS. Google recommends thatyou enable DNS query logging at least 24 hours before the migration to establisha pre-migration baseline.

After you have collected enough data in the DNS query logs, you can performthe zonal DNS migration. You can monitor DNS resolution rates during themigration to ensure that the migration doesn't cause an increase in DNS queryfailures.

Analyze and compare DNS name resolution rates

Use the following to analyze and compare the error and success rates.

  • Log Counts: For each query and time period, Logs Explorer shows thenumber of log entries found. A significant increase inNXDOMAIN countspost-migration for DNS names that previously resolved (hadNOERROR) couldindicate a problem.

  • Histogram: The Logs Explorer interface includes a histogram. Whenyour queries are run, the histogram shows the frequency of matching logentries over the selected time range. This is useful for visualizing:

    • A baseline rate ofNXDOMAIN log entries before migration.
    • Any spikes inNXDOMAIN log entries immediately after migration.
    • Changes in the rate ofNOERROR log entries.

    To see the histogram, clickPreferences, and then clickView,and then clickShow timeline.

What's next

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-12-15 UTC.