Suppose you received a request to create a new zone called my-zone.com so that the vm-a (10.0.1.2) and vm-b (10.0.0.3) Compute Engine VMs that are deployed in my-vpc-network can communicate with each other using the vm-a.my-zone.com and vm-b.my-zone.com FQDNs. Follow these steps:
- To create a new DNS zone, go to the Cloud DNS view in the Network services section. First, you need to specify Zone type, either Private or Public, and a zone name – that is, my-zone.com. In this case, it will be a private zone. Also, you need to specify which VPC is allowed to see my-zone.com. Both VMs use my-vpc-network, so this one should be selected:
Figure 9.29 – Creating a private zone my-zone.com
- Once the zone has been created, you need to add the vm-a and vm-b Compute Engine VMs to RECORD SETS. A record set is a collection of DNS records in a zone that share the same DNS name and type:
Figure 9.30 – Zone details view for Cloud DNS
- When you create a record set for a Compute Engine VM, you only need to provide its name and IP address. As shown in the following screenshot, for vm-b, it will be 10.0.1.3. The DNS name for vm-b will be vm-b.my-zone.com:
Figure 9.31 – Creating a record set for vm-b
- When a record set is created, it is visible in the Zone details view:
Figure 9.32 – Creating a record set for a Compute Engine VM
- Once a zone has been set up, you can SSH to vm-a and check if vm-b.my-zone.com is resolved to 10.0.1.3, as presented in the preceding figure.
Now that we know how to set up a DNS zone for Google Cloud workloads, it’s worth exploring the possibilities of using DNS services in hybrid cloud environments.
DNS forwarding for hybrid environments
In architectures where workloads that are on-premises and in Google Cloud need to communicate, along with VPN or Interconnect setup, DNS servers need to be configured so that on-premises sites can resolve Google Cloud zones and vice versa. A process where DNS queries are not handled by an initial server but are forwarded to another one is called DNS forwarding.
With Cloud DNS, you can configure the following:
- Outbound forwarding: This is where queries are forwarded from Cloud DNS to a DNS on-premises for a specified private zone and a VPC.
- Inbound forwarding: This is where queries are forwarded from a DNS on-premises to Cloud DNS for a specified private zone.
- Alternative DNS Server as a DNS policy: This is where no zone is defined. All queries from a specified VPC are forwarded to an external DNS server.
Note that you cannot configure forwarding to another VPC. However, if you want VPC-A to forward queries for a specific zone defined in VPC-B, you can achieve this by setting up DNS peering. At this point, Cloud DNS in VPC-B can either resolve the address locally or have a forwarding set for this zone to send queries, for example, to a DNS on-premises. Also, VPC peering is not required for DNS peering to work.
Let’s investigate the most popular case for hybrid environments: outbound forwarding. The following figure presents a Google Cloud project with a VPC called my-vpc-network:
Figure 9.33 – Cloud DNS outbound forwarding for a zone, on-prem.com, for on-premises DNS
The VPC uses a Cloud DNS zone called on-prem.com that’s been configured to forward queries outside Google Cloud to on-premises DNS 10.99.99.2. This VPC is connected to an on-premises environment via a VPN connection. Both sides exchange routing information via BGP. When a VM, vm-a, in the my-vpc-network VPC queries on-prem.com, Cloud DNS forwards this query to DNS on-premises. For the DNS to respond to the query on-premises, Cloud Router needs to advertise a Cloud DNS IP range of 35.199.192.0/19. Addresses from this range are used by Cloud DNS for communication. Although it is from a public IP space, it is not routable over the internet. Therefore, this communication is private and this range needs to be specifically allowed by a firewall on-premises. Once the DNS on-premises sends a reply to Cloud DNS, it will be forwarded to vm-a.
So far, we have covered creating and connecting VPCs, setting up firewall rules for workload protection, and ensuring cloud-to-on-premises connectivity. We’ve also explored the DNS service. However, to achieve optimal network efficiency, there is one important service remaining that we need to discuss – the load balancing service.