Understanding GCP Projects and Project-Level Cloud DNS

Projects are a fundamental part of Google Cloud’s identity, governance, and resource-management structure. They are much more than containers used to organize cloud resources.

A Google Cloud project serves as a boundary for:

• Resource ownership
• Identity and Access Management
• Billing attribution
• API enablement
• Service quotas
• Logging and monitoring
• Network configuration
• Resource lifecycle management

Cloud DNS follows this same project-oriented model. DNS zones are created inside a Google Cloud project, but their visibility—especially for private DNS zones—is determined by the VPC networks authorized to use them.

Understanding this distinction is essential when designing DNS for a single project, multiple projects, a Shared VPC, or an entire Google Cloud organization.

The GCP Resource Hierarchy

Google Cloud organizes resources into a hierarchical structure:

Organization
└── Folders
    └── Projects
        └── Cloud resources

The organization is the highest-level resource and normally represents the company or enterprise.

Folders are optional administrative containers used to group projects by:

• Business unit
• Department
• Environment
• Application
• Geographic region
• Security classification
• Regulatory boundary

Projects contain the actual cloud resources, such as:

• Compute Engine virtual machines
• Cloud Storage buckets
• BigQuery datasets
• GKE clusters
• VPC networks
• Cloud DNS zones
• Service accounts
• Load balancers

Google describes the project as the fundamental organizing entity required to enable and consume most Google Cloud services. IAM policies and organization policies assigned to an organization or folder can be inherited by the projects below them. Google Cloud resource hierarchy documentation

Why Projects Matter

A project is not merely a folder for cloud resources. It creates several important operational and governance boundaries.

1. Resource Boundary

Most Google Cloud resources belong to a specific project.

For example, a Compute Engine instance is created in a project. Its disks, service account, firewall policies, logs, and network dependencies are also associated with one or more projects.

The project establishes:

• Who owns the resource
• Who can administer it
• Which APIs the resource can use
• Where its usage is recorded
• Which policies apply to it
• How it is billed

Deleting a project also initiates deletion of the resources owned by that project. Therefore, projects represent important lifecycle boundaries.

2. IAM and Access Boundary

Projects are important IAM policy attachment points.

Administrators can assign roles at the:

• Organization level
• Folder level
• Project level
• Individual-resource level, where supported

For example, a user might receive:

• Viewer access to the entire organization
• Network Administrator access to a networking folder
• Compute Administrator access to one project
• DNS Administrator access to a specific DNS zone

Permissions granted at the organization or folder level are inherited by the projects below them. Permissions can also be assigned directly at the project level.

A project is therefore an access boundary, but not necessarily an isolated identity domain. Its effective permissions are the combination of:

• Organization-level IAM policies
• Folder-level IAM policies
• Project-level IAM policies
• Resource-level IAM policies
• IAM deny policies
• Organization Policy constraints

This inheritance model makes it possible to manage common permissions centrally while granting application-specific access at the project level.

3. Billing Boundary

Every billable project is linked to a Cloud Billing account.

The billing account pays for the resources consumed by the project, while the project provides a practical unit for cost allocation and reporting.

This allows organizations to analyze cloud spending by:

• Project
• Application
• Business unit
• Environment
• Cost center
• Development team
• Customer
• Product

For example:

Billing Account
├── Project: ecommerce-production
├── Project: ecommerce-development
├── Project: data-analytics
└── Project: shared-networking

All four projects can be paid for by the same billing account while still generating separate project-level cost data.

Labels and tags can provide even more granular cost allocation within a project, but the project remains one of the primary billing and reporting dimensions.

4. API and Service Boundary

Google Cloud APIs are generally enabled at the project level.

To use Cloud DNS in a project, for example, the Cloud DNS API must be enabled in that project. Enabling Cloud DNS in one project does not automatically enable it in every other project within the organization.

The same model applies to services such as:

• Compute Engine
• Cloud Storage
• BigQuery
• Google Kubernetes Engine
• Secret Manager
• Cloud Key Management Service
• Vertex AI

API usage, service agents, and many service quotas are also associated with the project.

5. Operational Boundary

Projects provide a useful boundary for:

• Logging
• Monitoring
• Alerting
• Security findings
• Audit trails
• Budget reporting
• Incident response

Logs can be stored within the project or routed to centralized logging projects. Similarly, security findings can be managed locally or aggregated through organization-level security services.

What Is Cloud DNS?

Cloud DNS is Google Cloud’s managed Domain Name System service.

It allows organizations to create and manage DNS zones and records without deploying or maintaining their own DNS servers.

Instead of operating DNS software on virtual machines, organizations can use Cloud DNS to manage records such as:

• A records for IPv4 addresses
• AAAA records for IPv6 addresses
• CNAME records for aliases
• MX records for email routing
• TXT records for verification and policy information
• SRV records for service discovery
• PTR records for reverse DNS
• NS records identifying authoritative name servers
• CAA records controlling certificate issuance

Because Cloud DNS is managed by Google, customers do not need to maintain the underlying DNS server operating systems, patching, clustering, or availability architecture.

Each Cloud DNS managed zone is created within a specific Google Cloud project. Google Cloud DNS zone documentation

Public and Private DNS Zones

Cloud DNS supports both public and private managed zones.

The major difference is who can query the DNS records.

Public Managed Zones

A public managed zone contains DNS records intended to be resolved through the public internet.

For example, an organization could create a public zone for:

example.com

It could then publish records such as:

www.example.com       A       203.0.113.20
api.example.com       A       203.0.113.30
mail.example.com      MX      mail-provider.example

When a public zone is created, Cloud DNS automatically assigns authoritative name servers and creates the required NS and SOA records.

The domain registrar must then be updated to delegate the domain to the Cloud DNS name servers.

Although the public zone belongs to a particular project, its records are publicly resolvable once delegation is configured. The project boundary controls administration and billing; it does not limit who can query a public zone.

Public zones are commonly used for:

• Corporate websites
• Public APIs
• Internet-facing load balancers
• Email-routing records
• Domain-verification records
• Public service endpoints

DNSSEC can be enabled for public zones to help protect DNS responses against certain types of forgery and cache-poisoning attacks.

Private Managed Zones

A private managed zone contains DNS records that are visible only to authorized VPC networks.

For example, an organization might create:

corp.example.com

with internal records such as:

database.corp.example.com    A    10.10.20.15
files.corp.example.com       A    10.10.30.25
api.corp.example.com         A    10.10.40.35

These names are not published to the public internet.

When creating the private zone, the administrator selects which VPC networks are authorized to query it. Only resources using those authorized VPC networks can resolve records in the zone.

This means that private DNS visibility follows the VPC network—not simply the project.

That distinction is critical.

Project Ownership Versus Network Visibility

Suppose a private DNS zone is created in Project A.

The following statement is not always correct:

Every resource in Project A can automatically resolve the private zone.

Resolution depends on the network used by the resource.

A VM in Project A can resolve the private zone if:

• It is connected to an authorized VPC network.
• It uses the Google Cloud metadata resolver or a properly configured DNS path.
• No higher-priority DNS policy or zone changes the resolution behavior.

Similarly, a resource in another project might be able to resolve the zone if it uses an authorized Shared VPC network or the zone is configured through an appropriate cross-project design.

Therefore, two separate controls must be considered:

Control	What it determines
Project ownership	Who manages and pays for the Cloud DNS zone
VPC authorization	Which networks can resolve a private zone

The Cloud DNS zone is a project resource, but the private zone’s reach is network-based.

Is There an Organization-Level DNS Configuration?

Google Cloud does not treat a managed DNS zone as a resource that is automatically created at the organization level and inherited by every project.

Cloud DNS managed zones belong to projects.

However, an organization can implement a centralized DNS architecture that functions as an enterprise-wide DNS service.

Common approaches include:

• Creating DNS zones in a dedicated networking project
• Using a Shared VPC
• Authorizing multiple VPC networks to use a private zone
• Using cross-project binding
• Creating DNS peering zones
• Creating forwarding zones
• Applying organization-level IAM and security policies
• Integrating Cloud DNS with on-premises DNS infrastructure

The result can provide organization-wide name resolution, but it must be explicitly designed. It does not occur merely because the projects belong to the same organization.

Project-Level Cloud DNS Configuration

A project can contain one or more public or private managed zones.

For example:

Project: application-production
├── Public zone: example.com
├── Private zone: prod.example.internal
├── VPC network: production-vpc
├── Compute Engine instances
└── Internal load balancers

The public zone can publish internet-facing application records.

The private zone can provide internal name resolution for resources using production-vpc.

Possible private records might include:

database.prod.example.internal
cache.prod.example.internal
internal-api.prod.example.internal
monitoring.prod.example.internal

This provides a clear separation between public and internal DNS.

However, not every project needs its own DNS zones. In larger environments, centralizing DNS administration is often more secure and manageable.

Common Cloud DNS Design Patterns

Pattern 1: Application-Owned DNS

In this model, each application project owns its DNS zones and records.

Application Project
├── Application resources
├── VPC network
├── Public DNS zone
└── Private DNS zone

This provides application teams with autonomy.

It can work well for:

• Small environments
• Independent applications
• Development and testing projects
• Decentralized operating models

The disadvantage is that DNS governance can become inconsistent across many projects. Teams might use different naming standards, security controls, and record-management processes.

Pattern 2: Centralized Public DNS

In a centralized design, public DNS zones are stored in a dedicated project.

Organization
├── Project: central-public-dns
├── Project: application-one
├── Project: application-two
└── Project: application-three

The central DNS project owns authoritative public zones such as:

example.com

Application teams request or automate records such as:

app1.example.com
app2.example.com
api.example.com

This provides:

• Centralized control
• Consistent naming
• Easier auditing
• Controlled DNS administrator access
• Reduced risk of accidental zone deletion
• Consistent DNSSEC management

Automation can still allow application teams to create approved records without giving them full control of the parent zone.

Pattern 3: Shared VPC with Centralized Private DNS

A Shared VPC allows an organization to place VPC networks in a host project and attach service projects to those networks.

A typical architecture might look like this:

Shared VPC Host Project
├── Shared VPC
├── Subnets
├── Firewall policies
└── Private Cloud DNS zones

Service Project A
└── Application VMs using Shared VPC subnets

Service Project B
└── GKE workloads using Shared VPC subnets

Service Project C
└── Data-processing resources using Shared VPC subnets

Because the workloads use the Shared VPC network, they can resolve private DNS zones authorized for that network—even though the workloads and DNS zones may be associated with different projects.

This is one of the most common enterprise patterns because it centralizes:

• Networking
• DNS
• Routing
• Firewall controls
• Hybrid connectivity

Application resources can remain in separate service projects for IAM, billing, and lifecycle isolation.

Pattern 4: Cross-Project DNS Binding

Cloud DNS supports cross-project binding for private zones.

This allows a private zone created in one project to be bound to a VPC network owned by another project within the same organization.

For example:

Project: central-dns
└── Private zone: corp.example.internal

Project: shared-networking
└── VPC: enterprise-vpc

The central DNS team can administer the zone, while the network team manages the Shared VPC.

This provides stronger separation of duties:

• DNS administrators manage zones and records.
• Network administrators manage VPCs and connectivity.
• Application teams manage workloads.
• Security teams define policies and audit activity.

Cloud DNS requires specific IAM permissions to bind a private zone to a network, helping ensure that one project cannot attach DNS zones to another project’s network without authorization.

Pattern 5: Split-Horizon DNS

Split-horizon DNS uses the same domain name but returns different answers depending on where the query originates.

For example:

Public answer:
portal.example.com → 203.0.113.20

Private answer:
portal.example.com → 10.20.30.40

Internet users receive the public IP address, while internal workloads receive the private IP address.

This design can be useful when:

• Internal users should access a private endpoint.
• Public users should access an external load balancer.
• The same hostname must work inside and outside the enterprise.
• Applications should not require separate internal and external URLs.

Split-horizon DNS must be designed carefully because private zones can override public DNS resolution for the same namespace.

Other Cloud DNS Zone Types

Beyond standard public and private managed zones, Cloud DNS supports additional configurations.

Forwarding Zones

A forwarding zone sends queries for a specific DNS namespace to designated DNS servers.

For example, Google Cloud might forward queries for:

corp.onprem.example.com

to on-premises Active Directory DNS servers.

Forwarding zones are useful in hybrid environments where some DNS records remain outside Google Cloud.

DNS Peering Zones

DNS peering allows one VPC network to use the DNS resolution capabilities of another VPC network.

This is different from VPC Network Peering. DNS peering provides name-resolution access; it does not provide network connectivity by itself.

Reverse-Lookup Zones

Reverse DNS zones provide mappings from IP addresses back to hostnames through PTR records.

They are useful for:

• Security investigations
• Monitoring tools
• Email infrastructure
• Legacy applications
• Compliance reporting
• Troubleshooting

Service Directory Zones

Service Directory DNS zones allow workloads to discover services registered in Google Cloud Service Directory through DNS queries.

This can help applications locate service endpoints without hard-coding IP addresses.

Creating a Public DNS Zone

The following command creates a public managed zone:

gcloud dns managed-zones create public-example-zone \
  --description="Public DNS zone for example.com" \
  --dns-name="example.com." \
  --visibility="public" \
  --project="dns-project-id"

After creating the zone:

1. Review the automatically assigned Cloud DNS name servers.
2. Log in to the domain registrar.
3. Replace the registrar’s existing name-server entries with the Cloud DNS name servers.
4. Add the required DNS records.
5. Test resolution from the public internet.

Creating the zone in Google Cloud does not automatically update the domain registrar.

Creating a Private DNS Zone

The following command creates a private zone associated with a VPC network:

gcloud dns managed-zones create private-example-zone \
  --description="Private DNS zone for internal workloads" \
  --dns-name="corp.example.internal." \
  --visibility="private" \
  --networks="production-vpc" \
  --project="dns-project-id"

Only resources using an authorized network can query records in this zone.

A private zone can be authorized for more than one VPC network when the architecture requires shared internal name resolution.

Creating DNS Records

After creating a managed zone, records can be added through the Google Cloud console, API, Terraform, or the Google Cloud CLI.

For example:

gcloud dns record-sets create database.corp.example.internal. \
  --zone="private-example-zone" \
  --type="A" \
  --ttl="300" \
  --rrdatas="10.20.30.40" \
  --project="dns-project-id"

The TTL determines how long resolvers can cache the record.

Lower TTL values can support faster changes but increase DNS query volume. Higher TTL values reduce query traffic but cause records to remain cached longer.

IAM Roles for Cloud DNS

Cloud DNS access should follow the principle of least privilege.

Common roles include:

• DNS Administrator: Can create and manage DNS zones and records.
• DNS Reader: Can view zones and records without changing them.
• DNS Peer: Provides permissions used in DNS peering scenarios.

Cloud DNS also supports IAM permissions on individual managed zones. This allows organizations to grant access to a specific zone rather than every zone in the project.

For example:

• The central networking team can administer all zones.
• The application team can manage only its delegated zone.
• Auditors can receive read-only access.
• Automation service accounts can update only approved records.

This is safer than granting broad project-level administrative roles to every application team.

DNS Resolution and Firewall Rules

DNS visibility does not automatically provide network connectivity.

A workload might successfully resolve:

database.corp.example.internal

to:

10.20.30.40

but still be unable to connect to the database.

The connection may be blocked by:

• Firewall rules
• Hierarchical firewall policies
• Routing configuration
• Network segmentation
• Missing VPC peering
• VPN or Interconnect problems
• Operating-system firewalls
• Application access controls

DNS answers the question:

What address belongs to this name?

DNS does not answer:

Is this workload allowed to connect to that address?

Name resolution and network connectivity must be tested separately.

Integrating Cloud DNS with On-Premises DNS

Hybrid environments often require bidirectional DNS resolution.

Google Cloud workloads may need to resolve on-premises names, while on-premises systems may need to resolve private Google Cloud names.

A hybrid DNS design may include:

• Cloud DNS forwarding zones
• Cloud DNS inbound server policies
• Cloud DNS outbound server policies
• On-premises conditional forwarders
• Cloud VPN or Cloud Interconnect
• Highly available on-premises DNS servers
• Clearly defined authoritative zones

For example:

Google Cloud workloads
        |
        | Query: server.corp.onprem.example.com
        v
Cloud DNS forwarding zone
        |
        v
On-premises DNS servers

In the opposite direction:

On-premises clients
        |
        | Query: app.gcp.example.internal
        v
On-premises conditional forwarder
        |
        v
Cloud DNS inbound forwarding endpoint

This allows both environments to resolve the names they require without duplicating DNS records.

Project-Level DNS Security Considerations

A strong Cloud DNS design should address the following risks.

Unauthorized Record Changes

An attacker or administrator with excessive permissions could redirect traffic by changing an A, CNAME, or MX record.

Use:

• Least-privilege IAM
• Dedicated DNS service accounts
• Multi-party approval for sensitive changes
• Cloud Audit Logs
• Infrastructure as Code
• Change-management controls

Accidental Zone Deletion

Deleting a public zone can disrupt internet-facing services. Deleting a private zone can affect internal applications, databases, and authentication systems.

Protect important DNS projects using:

• Restricted IAM
• Project liens where appropriate
• Infrastructure as Code
• Exported configuration backups
• Change reviews
• Monitoring for administrative activity

Public Exposure of Internal Records

Internal hostnames and private IP addresses should generally be placed in private zones, not public zones.

Before adding a record, verify whether it should be visible to:

• The public internet
• One VPC
• Several VPCs
• Shared VPC workloads
• On-premises systems
• Partner networks

DNS Namespace Conflicts

Private zones can override public DNS results for matching namespaces.

For example, creating a private zone for:

example.com

means authorized VPC networks will consult the private zone for that namespace. If the private zone does not contain records that exist in the public zone, internal clients might receive failed responses rather than automatically falling back to public DNS.

Private namespaces and split-horizon designs must therefore be planned carefully.

Recommended Enterprise Architecture

For a larger organization, a practical model is:

Organization
├── Folder: Shared Infrastructure
│   ├── Project: Shared VPC
│   ├── Project: Central Public DNS
│   ├── Project: Central Private DNS
│   ├── Project: Central Logging
│   └── Project: Security Services
│
├── Folder: Production
│   ├── Project: Application A
│   ├── Project: Application B
│   └── Project: Data Platform
│
└── Folder: Nonproduction
    ├── Project: Development
    ├── Project: Testing
    └── Project: Sandbox

In this model:

• Projects separate resources, access, billing, and lifecycle.
• Folders group projects and provide policy-inheritance points.
• Public DNS is centrally controlled.
• Private DNS is associated with approved VPC networks.
• Shared VPC provides centralized networking.
• Application teams manage workloads without receiving unrestricted DNS control.
• Logging and security monitoring are aggregated centrally.

Cloud DNS Best Practices

Separate Public and Private DNS

Do not mix public and internal records without a clear design.

Use public zones for internet-accessible services and private zones for internal resources.

Centralize Critical Zones

Critical corporate domains should normally be managed in dedicated DNS projects rather than application projects.

This reduces the risk that deleting or modifying an application project will affect the organization’s primary DNS zones.

Use Shared VPC for Centralized Networking

Shared VPC provides a clean separation between network ownership and workload ownership.

It also simplifies private DNS when many service projects use the same centrally managed network.

Use Consistent Naming Standards

Define conventions for:

• Environments
• Applications
• Regions
• Service types
• Internal domains
• Public subdomains

For example:

api.prod.us-central1.example.internal
database.dev.us-east1.example.internal

Manage DNS as Code

Use Terraform or another controlled automation framework to manage important DNS zones and records.

Infrastructure as Code provides:

• Version history
• Peer review
• Repeatability
• Easier recovery
• Reduced configuration drift
• Consistent deployment across environments

Monitor DNS Changes

Enable and review Cloud Audit Logs for DNS administration.

Alert on sensitive activities such as:

• Zone creation
• Zone deletion
• Name-server changes
• MX record changes
• Public-record changes
• IAM-policy changes

Enable DNSSEC Where Appropriate

DNSSEC should be considered for public zones to help protect the authenticity of DNS responses.

Its implementation must include proper coordination with the domain registrar.

Avoid Granting Broad Project Roles

Do not grant Project Owner merely because someone needs to modify DNS records.

Use Cloud DNS-specific roles or managed-zone IAM permissions whenever possible.

Conclusion

Projects are a foundational element of Google Cloud architecture. They define important boundaries for resources, access, billing, APIs, operations, and lifecycle management.

Cloud DNS fits into this structure because every managed DNS zone is created in a project. However, the project that owns a private zone does not, by itself, determine which workloads can resolve it.

The key distinction is:

The project determines ownership, administration, and billing. The authorized VPC network determines private DNS visibility.

Public zones can be queried from the internet after the domain is delegated to Cloud DNS. Private zones are visible only to approved VPC networks and properly integrated hybrid environments.

For smaller environments, DNS zones can be managed within individual application projects. For larger organizations, centralized DNS projects, Shared VPC, cross-project binding, IAM separation, and Infrastructure as Code usually provide a more secure and scalable architecture.