DNS in GCP: VPC Resolver, Cloud DNS, and Private Zones Explained

Simple explanation

DNS translates human-readable names into IP addresses. When a VM in GCP tries to reach my-database.internal or api.example.com, DNS figures out the IP address it should connect to.

Inside GCP, DNS works at two levels:

• The built-in VPC resolver: present in every VPC, handles internal VM names and forwards public queries automatically. You never create it and you rarely need to configure it.
• Cloud DNS: a managed service you opt into when you want to control DNS records yourself. You use it to host a public domain, create private internal names, or forward queries to an on-premises DNS server.

How DNS works in GCP

When a VM needs to resolve a name, the query follows a path through the VPC resolver:

1. The VM sends a DNS query to the VPC resolver at 169.254.169.254 (configured automatically via DHCP).
2. The resolver checks whether the name matches an internal GCP name, for example a Compute Engine VM hostname ending in .internal.
3. If a private Cloud DNS zone is attached to the VPC, the resolver checks that zone next.
4. If a DNS forwarding zone is configured, queries for matching domains are sent to a designated on-premises or custom DNS server.
5. For everything else, the resolver forwards the query to Google’s public DNS infrastructure.

Cloud DNS sits alongside the resolver. It provides the authoritative data for zones you manage. The resolver does the actual lookups; Cloud DNS is where the records live when you create your own zones. For more detail on how VPC networks are structured, the VPC networking page covers the underlying infrastructure.

The built-in VPC DNS resolver

Every GCP VPC has a DNS resolver that VMs use automatically. You do not provision it, configure it, or pay for it separately. VMs are pointed to it via DHCP when they start.

Where to reach it

• 169.254.169.254: the same link-local address as the metadata server, which also handles DNS queries
• The .2 address of the subnet CIDR: for example, if your subnet is 10.10.0.0/24, the resolver is also at 10.10.0.2

Both addresses are always valid. Most tooling and documentation uses 169.254.169.254. See the subnets page for how subnet CIDRs are assigned if this is new to you.

What it resolves

• Internal GCP resource names: VM hostnames, Cloud SQL private hostnames, and similar
• Private Cloud DNS zones that are attached to the VPC
• Forwarding zones: queries for specific domains sent to an on-premises or custom DNS server
• Any public name, forwarded to Google’s public DNS infrastructure

When you do not need to think about it

For most workloads running entirely inside GCP, the VPC resolver handles everything without any configuration. You only need to interact with it directly when debugging resolution failures or configuring custom forwarding behaviour. If you hit a DNS issue, the DNS resolution troubleshooting guide covers how to diagnose what is going wrong.

Internal DNS for Compute Engine VMs

Every Compute Engine VM automatically gets an internal DNS name. These names are predictable and stable. They do not change when the VM is restarted, and they always resolve to the VM’s primary internal IP address.

Name formats

• INSTANCE_NAME.ZONE.c.PROJECT_ID.internal: zone-specific fully qualified name, for example my-vm.europe-west1-b.c.my-project.internal
• INSTANCE_NAME.c.PROJECT_ID.internal: resolves across all zones in the project

Why this matters in practice

Use these names instead of IP addresses when services need to communicate with each other. Internal IP addresses can change when a VM is recreated or when you modify its network interface. DNS names do not. If your application has an IP address hardcoded and that VM gets replaced, the connection breaks. If it uses the DNS name, it keeps working.

# From inside another VM, check that internal DNS resolves correctly
nslookup my-vm.europe-west1-b.c.my-project.internal 169.254.169.254

If that lookup fails, the issue is almost always firewall rules, the VPC configuration, or the VM being in a different VPC without peering. Check the networking troubleshooting guide for a structured approach.

Cloud DNS explained

Cloud DNS is GCP’s managed authoritative DNS service. Authoritative means it is the definitive source of truth for the zones you create in it. When resolvers ask for records in your zone, Cloud DNS answers with what you have configured.

You use Cloud DNS when you need to manage DNS records yourself. That might be hosting a public domain, creating stable internal names for services inside your VPC, or routing DNS queries in a hybrid environment. You do not use it just to make VMs find each other — that is already handled by the VPC resolver.

Cloud DNS is fully managed. There are no DNS servers to provision, no software to update, and it is designed to be globally available with low latency. You interact with it through the GCP Console, the gcloud CLI, or the API. The Cloud DNS setup guide walks through creating zones and adding records step by step.

Public zones vs private zones

Public zones

A public zone is authoritative for a domain on the public internet. If you own example.com, you can host it in Cloud DNS and manage all its records through GCP — A, AAAA, MX, TXT, CNAME, and so on. You then update your domain registrar to point NS records to the Cloud DNS name servers, and Cloud DNS becomes the authority for that domain.

Public zones are the right choice when you want a single place to manage DNS for an internet-facing domain, when you need programmatic control over records as part of a deployment pipeline, or when you want DNSSEC support.

Private zones

A private zone resolves only from within the VPCs you specify. It is not visible on the public internet. You use private zones to create internal service names that are stable and human-readable, for example db.internal.mycompany.com pointing to a Cloud SQL instance, or payments-api.internal pointing to an internal load balancer.

Private zones are also used to override a public domain inside your VPC. If you want a name to resolve differently inside your network than it does on the internet, a private zone with the same name takes precedence. The full setup and use cases are covered on the private DNS zones page.

DNS record types you will actually use

Cloud DNS supports all standard record types. These are the ones you will encounter most often:

• A: maps a hostname to an IPv4 address. Most common record type.
• AAAA: maps a hostname to an IPv6 address.
• CNAME: an alias that points one hostname to another hostname. Useful for subdomains that should follow the same address as a root record.
• MX: mail exchanger; directs email for a domain to the right mail servers.
• TXT: arbitrary text records used for domain ownership verification, SPF email policy, DKIM signing keys, and similar.
• NS: name server records that delegate a subdomain to a different set of name servers.
• SOA: start of authority; contains zone metadata. Cloud DNS manages this automatically and you do not edit it directly.

When you create a record in Cloud DNS, you set the record type, the name (for example api.example.com), the value (for example an IP address), and a TTL.

TTL explained simply

TTL, or time to live, is a number in seconds that tells resolvers how long to cache a DNS record before checking again. It is set per record in Cloud DNS.

• High TTL (3600+ seconds): resolvers cache the record for a long time. DNS query volume is lower, but changes take longer to propagate everywhere.
• Low TTL (30–300 seconds): resolvers refresh more frequently. Changes propagate faster, but you generate more DNS queries.

The practical rule for migrations

If you know you are going to change a DNS record — for a domain cutover, a service migration, or an IP change — lower the TTL well in advance. The recommended approach:

1. At least 24 to 48 hours before the change, reduce the TTL to 60 or 300 seconds.
2. Make the actual record change.
3. Wait for the change to propagate (which now only takes minutes, not hours).
4. Once confirmed stable, raise the TTL back to a comfortable value.

DNSSEC

DNSSEC (DNS Security Extensions) adds cryptographic signatures to records in public zones. When a resolver queries a DNSSEC-enabled zone, it can verify that the response is genuine and has not been tampered with in transit.

Enabling DNSSEC in Cloud DNS is done with a single command, but it requires one additional step at your domain registrar: you must publish a DS record that Cloud DNS generates. Without this step, the trust chain from the DNS root to your zone is broken, and resolvers that enforce DNSSEC validation will treat your domain as failing validation.

# Enable DNSSEC on an existing public zone
gcloud dns managed-zones update my-public-zone \
  --dnssec-state=on

# Get the DS record to add at your registrar
gcloud dns dns-keys describe 0 \
  --zone=my-public-zone \
  --format="get(dsRecord)"

When to use Cloud DNS vs the built-in resolver

The right tool depends on what you are trying to do:

• VMs resolving each other by hostname: the VPC resolver handles this automatically. No Cloud DNS required.
• Hosting a public internet domain: create a public zone in Cloud DNS and delegate your domain to its name servers.
• Internal service names inside a VPC: create a private zone in Cloud DNS and attach it to your VPC. This is how you get stable, human-readable names for databases, internal APIs, or service endpoints.
• Hybrid networking, forwarding queries to on-premises DNS: configure DNS forwarding zones in Cloud DNS so queries for your corporate domain are sent to your on-premises DNS servers. This requires Cloud VPN or Cloud Interconnect for the network path. See the hybrid connectivity overview for context.
• Overriding a public name inside your VPC: create a private zone with the same domain name. Private zones take precedence over public resolution for VMs in the associated VPC.

Resolver vs Cloud DNS

Here is a quick comparison to clarify when each applies:

Public DNS vs private DNS at a glance

Real example scenarios

1. Internal app resolving another VM by hostname

You have two VMs in the same VPC: web-server and app-server. The web server needs to send requests to the app server. Instead of hardcoding 10.10.0.5, you configure the web server to call app-server.us-central1-a.c.my-project.internal. The VPC resolver handles this automatically. If the app server VM is ever replaced, its internal DNS name stays the same and the connection keeps working.

2. Public website hosted in Cloud DNS

You own mycompany.com and want to manage its DNS from GCP. You create a public zone in Cloud DNS for mycompany.com, add A records pointing to your load balancer IP, and update your domain registrar’s NS records to point to the Cloud DNS name servers. From that point on, all DNS for mycompany.com is managed through Cloud DNS. Records can be updated using gcloud or the Console, and changes propagate within seconds.

3. Internal database hostname using a private zone

Your team wants to connect to a Cloud SQL instance using the name db.internal.mycompany.com rather than the automatically assigned IP. You create a private Cloud DNS zone for internal.mycompany.com, associate it with your VPC, and add an A record pointing db to the Cloud SQL private IP. VMs in your VPC can now resolve db.internal.mycompany.com. If the Cloud SQL instance is replaced or migrated, you update one DNS record rather than reconfiguring every application that connects to it.

4. Hybrid environment forwarding a corporate domain to on-premises DNS

Your organisation has an on-premises network connected to GCP via Cloud VPN. The on-premises DNS server handles corp.mycompany.internal. You want GCP VMs to be able to resolve hostnames in that domain. You configure a DNS forwarding zone in Cloud DNS for corp.mycompany.internal, pointing to the on-premises DNS server IP. The VPC resolver then forwards queries for that domain through the VPN to the on-premises server. See the hybrid connectivity overview for how the network layer works.