Give app teams autonomy over their DNS records with Cloud DNS peering

In large Google Cloud environments, Shared VPC is a very scalable network design that lets an organization connect resources from multiple projects to a common Virtual Private Cloud (VPC) network, so that they can communicate with each other securely and efficiently using internal IPs. Typically shared by many application teams, a central team (or platform team) often manages the Shared VPC’s networking configuration while application teams use the network resources to create applications in their own service projects.

In some cases, application teams want to manage their own DNS records (e.g., to create new DNS records to expose services, update existing records…). There’s a solution to support fine-grained IAM policies using Cloud DNS peering. In this article, we explore how to use it to give your application teams autonomy over their DNS records, while ensuring that the central networking team maintains fine-grained control over the entire environment.

Understanding the Cloud DNS peering solution

Imagine that you, as an application team (service project) owner, want to be able to manage your own application (service project) DNS records without impacting other teams or applications. DNS peering is a type of zone in Cloud DNS that allows you to send DNS requests from a specific sub-domain to another Cloud DNS zone configured in another VPC—and it lets you do just that!

Cloud DNS peering is not to be confused with VPC peering, and it doesn’t require you to configure any communication between the source and destination VPC. All the DNS flows are managed directly in the Cloud DNS backend: each VPC talks to Cloud DNS and Cloud DNS can redirect the queries from one VPC to the other.

So, how does DNS peering allow application teams to manage their own DNS records? By using DNS peering between a Shared VPC and other Cloud DNS zones that are managed by the application teams.

For each application team that needs to manage its own DNS records, you provide them with:

• Their own private DNS subdomain (for example <applicationteam>.<env>.<customer>.gcp.com)

• Their own Cloud DNS zone(s) in a dedicated project, plus a standalone VPC with full IAM permissions

You can then configure DNS peering for the specific DNS subdomain to their dedicated Cloud DNS zone. In this VPC, application teams have Cloud DNS IAM permissions only on their own Cloud DNS instance and can manage only their DNS records.

The central team, meanwhile, manages the DNS peering and decides which Cloud DNS instance is authoritative for which subdomain, thus allowing application teams to only manage their own subdomain. 

By default, all VMs in the Shared VPC use Cloud DNS in the Shared VPC as their local resolver. This Cloud DNS instance answers for all DNS records in the Shared VPC, uses DNS peering to the application teams’ Cloud DNS instances and VPC peering or forwarding to on-prem for on-prem records.

As detailed above, the flow is the following:

• A VM in any project of the Shared VPC uses Cloud DNS as its local DNS resolver.

• This VM tries to resolve app1.team-b.gcp.com, which is a DNS record owned by team B that exposes a local application (a Compute Engine instance or a Cloud Load Balancer).

• This VM sends the DNS request to the Shared VPC Cloud DNS. This Cloud DNS is configured with DNS peering that sends everything under the “team-b.gcp.com” subdomain to Cloud DNS in the DNS project for team B.

• Team B is able to manage its own DNS records, but only in its dedicated DNS project. It has a private zone there for “*.team-b.gcp.com” and an A record for “app1.team-b.gcp.com” that resolves to “10.128.0.10”.

• When the VM receives its DNS answer, it tries to reach 10.128.0.10 using the VPC routing table. If the corresponding firewall rules are open, the request is successful!

Terraform code

Are you interested in trying out this solution for yourself? You can find an end-to end-example in Terraform, which provisions the following architecture:

This Terraform code should allow you to get started quickly and can be reused to integrate this design into your Infrastructure as Code deployment. 

Additional considerations

In the above example, we used a standalone project dedicated to DNS per application team. 

You can also use the application team’s service project by creating a local VPC in the application project and configuring DNS peering to this local DNS project.

The tradeoffs are the following:

Security and autonomy

Many organizations need the security and centralized control that Shared VPC provides. But with this architecture based on Cloud DNS peering, you can also grant application teams the autonomy they need to maintain their own DNS records—freeing the central networking team from that burden! For more on managing complex networking environments, check out this document on DNS best practices.