In order to use all the features of Cloud DNS, you need to be aware of policies. In this lesson, I'm going to describe what DNS policies are and what they can do. Cloud DNS policies allow you to override Cloud DNS settings. Policies can be simple, like enable login, or they can be more advanced. To help you understand when you might need to use a policy, let's think about the following scenario. Say your company is using the hybrid Cloud architecture and it has multiple authoritative DNS servers. You have some on-prem resources, running under an on-prem DNS server, and you have some GCP resources running under Cloud DNS.

In order to make both systems work together, you have a few options. Number one, you can handle all DNS resolution on-premises. Number two, you can handle all DNS resolution with cloud DNS, or number three, you can set up a hybrid DNS environment.

First, let's talk about handling all DNS resolution on-premises. This can be achieved by adding a Cloud DNS policy that specifies an alternative name server. An alternative name server tells Cloud DNS to forward all requests to the specified server. This effectively bypasses Cloud DNS for name resolution. You can think of it as being similar to DNS forwarding, except it applies globally to all domains. Now, be aware, if you choose to move all your GCP DNS resolution to on-premises, there will be some trade offs.

First, DNS requests from GCP are going to have a higher latency. Second, if your on-prem connection is ever disrupted, then your GCP resources will not be able to resolve any DNS names. Third, it's going to be more difficult to support highly flexible GCP environments, such as autoscaled instance groups. And fourth, you might not be able to use certain GCP products, ones that rely on reverse DNS resolution of instance names, for example, Dataproc.

All right, next, let's talk about the second option, handling all DNS resolution with Cloud DNS. Now, this can be achieved via another DNS policy that enables inbound query forwarding. Now, by default, a VPCs name resolution services are only available to that VPC itself. However, you can create an inbound server policy to share these name resolution services with other networks, either via Cloud VPN, or cloud Interconnect. Now, in this setup, all your on-prem DNS requests are going to be sent to Cloud DNS. Similar to the first solution, this design also suffers a few drawbacks.

First, your on-prem DNS requests will have a higher latency. And second, if your connection to GCP is ever disrupted, your on-prem resources will not be able to resolve any DNS names. So while you can choose between either a 100% on-prem, or 100% cloud DNS strategy, it's generally recommended that you go with a hybrid one instead. You can use Cloud DNS for your Google resources, and your on-prem DNS server for your on-prem resources.

Now, this setup is slightly more complex, but it gives you the best of both worlds. Here is what a hybrid setup would look like. To access on-premises resources from Google Cloud platform, you would need to set up a forwarding zone for your corporate domain. You do not wanna use an alternative name server here. That would cause you to lose access to compute engine internal DNS names. Also, all public IP resolution would have an extra hop added, as they too would be routed through your on-premises name server. A forwarding zone here is the better option.

Next, to access GCP from on-premises, you would create a DNS server policy that enabled inbound DNS forwarding. Inbound DNS forwarding will allow your on-prem systems to query all private zones in the project, as well as internal DNS IP addresses and peered zones. Once this policy is added, Cloud DNS will create a set of regional IP addresses. You will then use this list to update your on-prem DNS and enable the appropriate forwarding. Now, this hybrid approach is considered a best practice by Google. It will generally offer the most options with the least headaches.