Google Cloud Account without Linked Card Setting Up Private Zones for GCP Internal DNS

GCP Account / 2026-04-28 13:21:42

Why “Private Zones” and Why You Should Care

If you’ve ever tried to make a bunch of services talk to each other inside Google Cloud using friendly names like orders.internal instead of numeric IP addresses, you’ve already discovered the magical mystery tour: DNS. DNS is the phonebook of the internet, the concierge of your cloud, and the tiny paperwork gremlin that refuses to move unless you fill out the right forms in the right order.

In GCP, when you want those names to resolve only inside your network (and not be published publicly), you use Private DNS Zones. A Private DNS Zone is basically a private authority for your domain, hosted by Google, that resolves names within selected VPCs. It’s like putting a local library card in your pocket: it works great in your neighborhood, and the rest of the world can’t even find the library.

This matters because:

Security: Your internal names don’t leak to the public DNS. Nobody on the outside should be casually googling “definitely-not-secret-payments.”
Reliability: You avoid hardcoding IPs and you can change services without rewriting every configuration file like it’s 2004.
Scalability: You can manage record updates centrally instead of relying on scattered, fragile setups.
Sane operations: Troubleshooting gets less like archaeology and more like solving a crossword puzzle.

Now let’s set up Private Zones for GCP Internal DNS in a way that doesn’t feel like you’re wrestling a spreadsheet wearing a trench coat.

Quick Mental Model: What You’re Actually Building

Before clicking buttons, you need a mental picture. Here’s the essence:

A Private DNS Zone corresponds to a DNS domain like internal.example.com.
The zone contains DNS records (A, AAAA, CNAME, TXT, etc.).
You attach the zone to one or more VPC networks so that instances in those networks can resolve the names.
GCP provides internal DNS resolution services to use those records within the attached networks.

If you’ve ever felt like DNS is a wizard behind a curtain, you’re not wrong. But the wizard has rules. The rules are just documented, which is the best kind of wizard—one that at least pretends to be a software engineer.

Deciding Your Domain Names: Be Pickier Than a Cat

The domain name you choose for your internal zone should be:

Consistent: Pick one naming scheme and stick to it. Future-you will send a thank-you note. Current-you will complain less.
Non-public: Use a domain you own, or use a dedicated internal domain like internal.yourcompany.com. Avoid anything that might conflict with public zones you later decide to use.
Logical: Consider environment separation: dev.internal.example.com, staging.internal.example.com, prod.internal.example.com.

Example planning decision:

Production zone: prod.internal.example.com
Staging zone: staging.internal.example.com
Dev zone: dev.internal.example.com

Now you get clean boundaries and fewer “why is staging answering my production request?” moments.

Choose Where the Records Come From: Static vs. Managed

Records in a private zone can be created and managed manually, or integrated with GCP services depending on your setup.

Common patterns:

Manual records: You create A/AAAA records for internal IPs of services or load balancers. Good for small setups or where you want tight control.
Service-driven records: Some GCP components can register records automatically (depending on the service and configuration). This helps reduce drift, but you still need to understand what gets registered and when.

If you’re starting from scratch, manual records are easiest to reason about. Once stable, you can decide what to automate so humans don’t have to do repetitive tasks like it’s the 1990s.

Networking Prerequisites: The Part People Skip (And Then Regret)

Google Cloud Account without Linked Card To make Private DNS work, you must understand how your VPC networks and DNS resolution paths interact.

In broad terms, you’ll need:

A VPC network where your instances live.
Appropriate IAM permissions to create and manage zones and records.
Decisions about whether you have multiple VPCs, peering, or shared VPC.
Optional: conditional forwarding if you rely on custom DNS for other domains.

If you’re using Shared VPC, keep in mind that DNS ownership and attachment still need to make sense. DNS isn’t just “there”; it’s a system that asks “which networks are allowed?” and then behaves accordingly.

Step-by-Step: Creating a Private DNS Zone in GCP

We’ll go through a typical setup workflow. The exact UI labels may vary slightly depending on Console updates, but the logic stays the same. Think of it like ordering pizza from a different location of the same chain: still pizza, slightly different menu font.

1) Pick your zone name and domain

Decide:

DNS Name: e.g., prod.internal.example.com
Zone ID (a short identifier used by GCP): e.g., prod-internal-zone

Tip: Choose a zone ID that’s easy to type in command-line contexts. You’ll be glad later. Your fingers deserve happiness.

2) Choose the visibility scope

Private DNS zones are “private” by design, but you still need to ensure they’re attached to the right VPC networks.

During creation, you’ll specify which VPC(s) can use this zone. If you’re not sure, start with only the networks that need it. It’s easier to broaden later than to explain why dev VMs can resolve prod services.

3) Attach the zone to the right VPC network(s)

This is where you either get DNS resolution working or you get to enjoy the thrilling hobby of debugging. DNS “not resolving” often boils down to “you attached the zone to the wrong network,” “the network doesn’t match what your VM uses,” or “you thought VPC A and VPC B were connected but they are not.”

In a simple case, you might attach to one VPC:

VPC name: main-prod

In a more complex case, you might attach to multiple VPCs that share connectivity patterns.

4) Create initial records

Let’s say you have an internal service reachable at:

Service: api.prod.internal.example.com
Target: internal IP 10.50.0.25 or a load balancer IP

You’d create an A record:

Name: api (relative to the zone)
Type: A
IPv4 address: 10.50.0.25

For IPv6 services, you’d use AAAA records instead.

5) Validate from a VM

Google Cloud Account without Linked Card Pick a VM instance inside the attached VPC, then test name resolution using tools like dig or nslookup (depending on what’s installed). The goal is: the VM should resolve your record to the expected IP.

For example:

Query: api.prod.internal.example.com
Expected: 10.50.0.25

If you don’t get a response, don’t panic. DNS debugging is a series of methodical checks, not a séance. Start with whether the zone is attached to the VM’s VPC and whether the record exists in the correct zone.

Record Types You’ll Actually Use (And What They Mean)

Not all DNS records are created equal. Some are simple like “point this name to this IP.” Others are like “here’s a string that’s meaningful only to applications that know what to do with it.”

Google Cloud Account without Linked Card A and AAAA Records

A maps a hostname to an IPv4 address. AAAA maps it to an IPv6 address. For most internal services that use standard networking, A records are the bread and butter.

CNAME Records

CNAME creates an alias. For instance, you might want:

orders.prod.internal.example.com is a CNAME to api.prod.internal.example.com

This is useful when you want multiple service names to point to the same underlying endpoint. But avoid creating cycles (aliases that ultimately point back to themselves), unless you enjoy a fun activity called “infinite DNS loops.”

TXT Records

TXT records store text. They’re commonly used for verification tokens and certain application features (like some domain ownership proofs). If you need TXT records, you’ll usually know why, because the application tells you. If you don’t know why, it’s often because the application will later ask for it and you’ll want to be ahead of the plot.

Handling Multiple VPCs: When “Attached” Isn’t the Whole Story

Attaching a private DNS zone to a VPC gives that VPC visibility into the zone. But if your services are spread across multiple VPCs (or you use peering, transit routing, or shared VPC patterns), the question becomes:

Which VPC is doing the DNS resolution for your clients?

Some key considerations:

If your client VM is in VPC A, it resolves DNS using what’s configured for VPC A. If the zone isn’t attached to VPC A, it won’t know your internal names.
If your client is in VPC B, attach the zone to VPC B or otherwise provide DNS reachability.
VPC peering provides network reachability, but DNS resolution is not automatically magical. Depending on how you configured things, you may need to attach zones appropriately.

Practical approach:

Attach the same private DNS zone to every VPC that needs to resolve the names.
If you have separate environments, use separate zones or at least separate record sets to avoid accidental cross-environment name resolution.

Split Horizon DNS: The “Same Name, Different Answer” Reality

Sometimes, you want the same hostname to resolve differently depending on context. This is called “split-horizon DNS.” Private DNS zones can help you implement this behavior by having different zones or record sets attached to different VPCs.

However, with power comes the obligation to not confuse your colleagues. If dev and prod return different IPs for the same name, document it. Otherwise you’ll someday hear a sentence like:

“It worked in dev, so why is prod on fire?”

DNS is not usually the spark, but it can be the arsonist’s accomplice when misconfigured.

Common Pitfalls (AKA: The “Why Is DNS Still Not Working?” Checklist)

Here are the typical reasons people lose an afternoon to DNS issues. Read these like a detective reads a list of suspects. You know someone did something, you just need to identify which “someone.”

1) The VM is not in the VPC attached to the zone

This is the classic. You create a zone, attach it to VPC X, and then test from a VM in VPC Y. Your query goes out, Google does its job, and it’s like:

“I don’t know that domain in this network. Try a different office.”

Fix: Confirm the zone is attached to the VPC where the VM lives. Double-check Shared VPC scenarios too.

2) The record is created in the wrong zone

Because humans create multiple zones. Humans also forget which is which. Then humans create records in the wrong one. DNS remains innocent until proven guilty.

Google Cloud Account without Linked Card Fix: Verify record exists under the exact intended zone and with the correct name relative to the zone (for example, api inside prod.internal.example.com becomes api.prod.internal.example.com).

3) IAM permissions are missing

Sometimes you can create zones but not records, or you can view but not modify, or automation fails silently because permissions are incomplete.

Fix: Ensure the service account or user has the necessary permissions for creating and managing Cloud DNS resources.

4) TTL caching makes changes look “stuck”

DNS uses TTL (time to live). If you update a record, clients might still be caching the old answer until the TTL expires.

Fix: Be patient or reduce TTL in initial phases. For troubleshooting, test with a resolver that doesn’t cache aggressively, or flush local caches if your environment allows it.

5) You’re expecting resolution across networks that aren’t attached

If you have multiple VPCs and expect a VM in VPC A to resolve using a zone attached only to VPC B, that won’t happen by default.

Fix: Attach the zone to all required VPCs, or implement a forwarding strategy.

6) Custom resolvers and conditional forwarding conflicts

If you have your own DNS server or conditional forwarding rules, you might end up querying somewhere else first, bypassing GCP’s internal resolution path.

Fix: Confirm the client’s resolver configuration. If you use Cloud DNS forwarding/conditional rules, ensure your internal domains match the right forwarding behavior.

DNS Forwarding and Conditional Rules: When You Need to Talk to More Than One Authority

Private zones help you resolve your internal domains. But what about all the other domains you still need, like google.com or github.com?

Most setups rely on standard resolution for public domains and private zones for internal ones. The tricky part happens when you integrate custom DNS, on-prem DNS, or specialized resolution paths.

Conditional forwarding means: “If someone asks for this domain, forward the query to that DNS server.”

A typical scenario:

Your VM asks for prod.internal.example.com
You want that answered by the GCP private zone
Your VM asks for corp.internal (an on-prem domain)
You want that forwarded to your on-prem DNS

The danger is misrouting queries: if conditional forwarding rules are too broad, internal queries might get sent to the wrong server; if too narrow, your internal queries might not go where you intended.

Best practice: Keep domain scopes specific, and document your forwarding rules so future you doesn’t have to play DNS psychic.

A Realistic Example Setup: Production Zone with a Few Services

Let’s build a sample scenario. Imagine a production environment with:

A VPC network: main-prod
Google Cloud Account without Linked Card A private domain: prod.internal.example.com
Services:

API at 10.50.0.25 (or a load balancer IP)
Auth at 10.50.0.30
Worker reachable via a stable IP 10.50.0.40

You’d create the private zone:

Zone name: prod.internal.example.com
Zone ID: prod-internal-zone
Attach to VPC: main-prod

Then records:

A record: api.prod.internal.example.com -> 10.50.0.25
A record: auth.prod.internal.example.com -> 10.50.0.30
A record: worker.prod.internal.example.com -> 10.50.0.40

Optionally, you might use CNAME for convenience:

Google Cloud Account without Linked Card CNAME: service.prod.internal.example.com -> api.prod.internal.example.com

Finally, validate:

Google Cloud Account without Linked Card From a VM in main-prod, run DNS queries for each hostname.
Optionally test connectivity to the returned IPs using application-level health checks or simple network checks.

Congratulations: you’ve taught your internal universe to use names instead of numbers. Small win, big morale.

Best Practices That Save You From Future You

Use separate zones per environment (dev/staging/prod), unless you have a strong reason not to. It’s the simplest way to prevent cross-environment confusion.
Use consistent record naming: api, auth, db, cache, etc. If names change randomly, your automation and docs will suffer.
Document your ownership model: Who creates records? Who updates them? Who approves changes? DNS changes are often operationally sensitive.
Prefer stable endpoints: If your services move, use load balancers or stable IP strategies rather than chasing instance IPs like you’re collecting Pokemon.
Test from the right network: Always validate DNS resolution from a VM in the VPC that should resolve the names.
Keep TTL reasonable: Low TTL helps fast changes but can increase query volume. Choose a balance based on how often records change.
Automate carefully: If you automate record creation, make sure you can audit what gets created. Invisible DNS automation is like a magic trick that also sets your alarms off.

Troubleshooting: A Methodical Approach (No Incantations Required)

When DNS fails, you want to answer a few key questions quickly:

Is the record in the right zone?
Is the zone attached to the VM’s VPC?
Does the VM actually use the expected DNS resolver?
Are there caching effects?
Are there forwarding rules overriding behavior?

Here’s a practical troubleshooting sequence:

Step 1: Confirm the hostname and zone. Make sure you’re querying the fully-qualified domain name that matches your zone and relative record name.
Step 2: Verify the record. Check the record type (A vs CNAME) and ensure the target value is correct.
Step 3: Confirm attachments. Inspect whether the private zone is attached to the exact VPC where the client resides.
Step 4: Test with dig/nslookup. Compare results from different VMs in different VPCs to isolate the attachment issue.
Step 5: Check DNS forwarding/conditional rules. If you use them, verify the internal domain isn’t being forwarded somewhere unexpected.
Step 6: Consider TTL and caching. Repeat after TTL expiry, or use a test environment with minimal caching.

If you do these steps in order, you’ll usually find the problem faster than the time it takes your team to start sending confusing screenshots.

Automation and Operations: Making DNS Changes Less “Heroic”

DNS tends to be a production-critical dependency. Even a “small” record change can break service-to-service communication. So treat DNS like it has a pager duty, because it does.

Operational strategies:

Use Infrastructure as Code: Define private zones and records declaratively so changes are tracked and repeatable.
Change management: Apply changes in controlled windows, especially in production.
Rollback plan: If you change records that map to critical services, have a rollback path ready.
Google Cloud Account without Linked Card Monitoring: Consider application checks that validate name resolution and connectivity.

And remember: DNS is not the place to test whether “versioning in production” is a real concept.

Security Notes: Least Privilege and Access Controls

Because DNS is a directory, controlling it is security-sensitive. Not everyone should be allowed to edit records willy-nilly. You want least privilege IAM roles for:

Creating zones
Managing records
Viewing records

Also, if multiple teams share networks, define responsibility boundaries. A shared DNS zone can be a gift or a curse. It depends on whether you have clear processes.

Conclusion: Your Internal Names Deserve Better Than IP Addresses

Setting up Private Zones for GCP Internal DNS isn’t about memorizing every button label. It’s about building a reliable, secure, and understandable name-resolution system. Start by picking a clear internal domain strategy, create a private DNS zone, attach it to the VPCs that need it, and manage records in a way that reduces drift and surprises.

When something doesn’t resolve, don’t resort to dramatic chanting. Use a checklist: confirm the zone, confirm attachments, confirm record types, and validate from the correct VPC. Once it’s working, use best practices and automation so the setup stays stable while your services evolve.

Do it well, and your team gets a system where services can find each other by name, confidently, repeatedly, and with minimal “what IP was that again?” moments. It’s DNS maturity. It’s internal peace. It’s you winning against the gremlins.