Understanding forwarding, peering, and private zones in Cloud DNS

The Domain Name System, or DNS, is one of the most foundational services of the Internet, turning human-friendly domain names into IP addresses. Often handled by specialized network engineers within an organization, DNS can feel like a black box to people who don’t deal with it often. For one, DNS terminology can be confusing, and some terms have different meanings in different parts of the cloud network (e.g. peering). But understanding how DNS works is critical, especially in a cloud environment, where you need DNS to make your applications available to enterprise users.

If you’re running on Google Cloud, chances are you use Cloud DNS, a scalable, reliable and managed authoritative DNS service running on the same infrastructure as Google. It has low latency, high availability and scalability and is a cost-effective way to make your applications and services available to your users.

One of the more complex DNS setups that customers struggle with is building multiple projects and VPCs, all of which need to establish connectivity back to an on-prem DNS resource. Unless there’s outside connectivity to an on-prem network or another cloud, VPCs logically look like “islands,” or self-contained networks. As such, a logical assumption would be that each VPC would use its own forwarding zone and individually forward DNS queries back to on-prem for resolution. 

However, isolating your VPCs from one another leads to challenges, and the more VPCs you have, the harder it becomes. First, let’s unpack why this is challenging, and then show you how to solve for it.

The trouble with handling DNS forwarding requests in multiple VPCs
The challenge is fundamentally a routing one. Google utilizes an egress proxy for all outbound DNS requests to the on-prem environment from an outbound forwarding zone. This highly available and scalable pool of proxies uses the same IP address block and does so for all VPCs. If you have multiple VPCs that forward DNS requests to the same on-premises network, it is not possible to create a route to send the response specifically to the originating VPC (because they are all using the same IP blocks for their proxies). The more VPCs using the pool of proxies you have, the greater the chances of sending things back to the wrong VPC. 

In the drawing below, two VPCs, A and B, are both set up with outbound forwarding zones to on-prem, and both the cloud routers A and B are advertising the DNS proxy range of 35.199.192.0/19. To the on-prem network, all traffic appears to originate from 35.199.192.0/19 and when a response is generated on-prem, the return traffic could end up in the wrong VPC network. In this scenario, the on-prem network has a 50/50 chance of guessing which VPC originated the request. And as more VPCs get introduced into the model, the chances of reaching the right source diminish rapidly.

Outbound forwarding zones and DNS peering for connecting multiple VPCs
In order to address the challenge of connecting multiple VPCs to an on-prem network, you need to use a combination of outbound forwarding zones alongside DNS peering in a hub-and-spoke model. The hub VPC utilizes DNS forwarding to perform the hybrid connection to the on-prem network and the spoke VPCs uses DNS peering to connect to the hub VPC. 

In the drawing below, a single outbound forwarding zone is set up in VPC H. All other VPCs peer with VPC H. Any queries set to be resolved from on-prem will now go from the originating VPC(A, B, or C in this example) to VPC H. Once in VPC H, it will identify this as part of the outbound forwarding zone, and forward the request to on-prem through established network connectivity. In this case, the 35.199.192.0/19 range is only being advertised from VPC H’s cloud router, therefore when the query is being routed back to Google Cloud, there is only a single VPC network path for that route. VPC H then cascades the appropriate information back to the originating VPC (A, B, or C) and everything functions as expected.

Keeping up with Cloud DNS
Managing DNS might not be your day job, but understanding how it works can be critical when configuring enterprise cloud environments. In this post, we’ve shown you how to use some of Google’s DNS constructs to connect multiple zones to your on-premises DNS infrastructure, using a combination of zones, peering, and forwarding. You can learn more about Google Cloud’s networking portfolio, including our DNS services, online and reach us at gcp-networking@google.com.