Probably the most common activity when working with Cloud DNS is to create or update DNS records. But before you can start modifying records, you need to be familiar with DNS zones. A DNS zone is a container of DNS records for the same DNS name suffix. All DNS records are stored within a zone. DNS zones also automatically generate certain records like the NS and SOA so you don't have to add them yourself.

Now, Cloud DNS offers two types of zones. Public and private. Public zones are visible to the whole internet. While private zones are only visible to the VPC networks that you specify. So, an internet-facing website would use a public zone but a company intranet site like a wiki would use a private zone. Now, there are times where you might want to mix both private and public zones. Now, this would allow you to return different results for the same domain name depending upon the source IP. This is called Split Horizon DNS.

So, let's imagine the following scenario. Say, you have a web server running in a VPC with both a public and private IP. Now, you want your internet users to be able to access this web server via the public IP. You also want internal resources such as other VMs to be able to access it via private IP. Split horizon DNS would allow you to use the same DNS name for both. Internet clients would get the public IP and internal clients would get the private IP.

Now, to set up split DNS, all you have to do is create both a public and private zone for the same domain. Then, just add the appropriate records. Public DNS zones can also be configured to enforce DNS security extensions. Now, DNS security extensions or DNSSEC is a feature that authenticates responses for domain name lookups. Now, before DNSSEC was introduced, you had to trust that your DNS results were accurate. But if a response was poisoned it could result in redirecting you to a different and potentially harmful server. By enabling DNSSEC for a zone, you can cryptographically verify that the data received actually came from where it was supposed to. You can also verify that the data was not modified in transit.

Now, zones can also be used for DNS Forwarding. Forwarding allows requests for certain domains to be resolved by another DNS server. Now, this is useful if you wanna resolve names that you do not control yourself. So, if say you were connecting from your on-prem environment to your GCP environment, you could use DNS forwarding to get access to private DNS records in GCP.

Now, forwarding can be either outbound or inbound. Outbound forwarding means that you will be forwarding DNS requests outside of Google Cloud platform. Inbound forwarding will be routing requests into Google Cloud platform. Another option you have with DNS zones is called peering. DNS peering works similarly to DNS forwarding but with one main difference. With DNS peering, you're allowing requests to be forwarded from one VPC to another for specific zones. This works regardless of whether the VPC networks are actually connected or not.

Now, this is important to note. DNS forwarding does not let you forward requests between VPCs nor does it support transitive routing. DNS forwarding only handles external to internal and internal to external routing. DNS peering is for internal to internal routing between VPCs. It also does support transitive routing, but only through a single hop. DNS peering can make it possible for your teams to independently manage their own DNS zones while also sharing them with the rest of your organization.

You should also be careful not to confuse DNS Peering with VPC Network Peering. They are different. VPC peering allows VMs in different projects to reach each other but it does not affect name resolution. DNS peering allows you to access DNS records in a different VPC, but it does not affect the connectivity of those VPCs. You can use both options at the same time but they do different things.