Best practices for Cloud DNS

This document provides best practices for private zones, DNS forwarding, and reference architectures for hybrid DNS.

It's easier for both humans and applications to use the Domain Name System (DNS) to address applications and services because using a name is easier to remember and more flexible than using IP addresses. In a hybrid environment that consists of on-premises and one or more cloud platforms, DNS records for internal resources often need to be accessed across environments. Traditionally, on-premises DNS records are manually administered by using an authoritative DNS server, such as BIND in UNIX/Linux environments or Active Directory in Microsoft Windows environments.

This document describes best practices for forwarding private DNS requests between environments to make sure that services can be addressed from both on-premises environments and within Google Cloud.

General principles

Learn about DNS concepts on Google Cloud

When you use DNS on Google Cloud, it's important to understand the different systems and services available in Google Cloud for DNS resolution and domain names:

Internal DNS is a service that automatically creates DNS names for virtual machines and internal load balancers on Compute Engine.
Cloud DNS is a service providing low latency and high availability DNS zone serving. It can act as an authoritative DNS server for public zones that are visible to the internet, or for private zones that are visible only within your network.
Managed Service for Microsoft Active Directory is a highly available, hardened service that runs Microsoft Active Directory, including a domain controller.
Public DNS is a Google service that is not part of Google Cloud that acts as an open, recursive DNS resolver.
Cloud Domains is a domain registrar for buying, transferring, and managing domains within Google Cloud. Cloud Domains lets you interact with the domain registration system through an API.

Identify stakeholders, tools, and processes

When you think about building a strategy for DNS in a hybrid environment, it's important to familiarize yourself with your current architecture and contact all stakeholders. Do the following:

Identify and contact the administrator of your organization's corporate DNS servers. Ask them for information about the configurations that are required to map your on-premises configuration to a suitable architecture on Google Cloud. For information about methods for accessing Google Cloud DNS records, see Use conditional forwarding for accessing DNS records from on-premises.
Familiarize yourself with the current DNS software and identify the domain names that are used privately within your organization.
Identify contacts on the networking team who can make sure that traffic to Cloud DNS servers is correctly routed.
Familiarize yourself with your hybrid connectivity strategy and with hybrid and multicloud patterns and practices.

Create a consistent naming standard

Create a naming standard that is consistent throughout your organization. For example, assume that your organization uses example.com as its second-level domain name and the domain for public resources (for example, www.example.com). Where the public zones are hosted is irrelevant for the purposes of this document because the scope is to migrate private zones.

For naming corporate resources on-premises, you can choose from the following patterns:

You can have different domain names for on-premises servers and for Google Cloud. This pattern uses a separate domain for your different environments—for example, corp.example.com for your on-premises servers and gcp.example.com for all resources on Google Cloud. If you use other public cloud environments, they can each have a separate subdomain. This is the preferred pattern, because you can forward requests between environments.

You can also use separate domain names such as example.com and example.cloud.
You can have the Google Cloud domain as a subdomain of the domain that contains on-premises servers. Using the example.com domain, on-premises could use corp.example.com, and Google Cloud could use gcp.corp.example.com. This is a common pattern when most of the resources remain on-premises.
You can have the on-premises domain as a subdomain of the domain that contains Google Cloud records. Using the example.com domain, Google Cloud could use corp.example.com and on-premises could use dc.corp.example.com. This is an uncommon pattern, but it might be used for digital organizations that have only a small footprint on-premises.
You can use the same domain for Google Cloud and for on-premises. In this case, both Google Cloud and on-premises use resources that use the corp.example.com domain. Avoid this pattern because it makes managing records in a hybrid environment much harder; it's possible only when you use a single authoritative DNS system.

The rest of this page uses the following domain names:

example.com as a domain name for your public records, regardless of where they're hosted.
corp.example.com as a zone hosted by your on-premises DNS server. This zone hosts records of your on-premises resources.
gcp.example.com as a Cloud DNS private managed zone that hosts records for your Google Cloud resources.

Figure 1 illustrates a domain name setup that is consistent across both your on-premises network and Google Cloud.

FIgure 1. Consistent domain name setup across your organization. — **Figure 1.** Domain name setup is consistent across the organization.

For naming resources within your Virtual Private Cloud (VPC) network, you can follow guidelines such as the ones in the solutions guide Best practices and reference architectures for VPC design.

Choose where DNS resolution is performed

In a hybrid environment, DNS resolution can be performed in different locations. You can do the following:

Use a hybrid approach with two authoritative DNS systems.
Keep DNS resolution on-premises.
Move all DNS resolution to Cloud DNS.

We recommend the hybrid approach, so this document focuses on that approach. However, for completeness, this document briefly describes the alternative approaches.

Use a hybrid approach with two authoritative DNS systems

We recommend using a hybrid approach with two authoritative DNS systems. In this approach:

Authoritative DNS resolution for your private Google Cloud environment is done by Cloud DNS.
Authoritative DNS resolution for on-premises resources is hosted by existing DNS servers on-premises.

Figure 2 shows this arrangement.

Figure 2. A hybrid DNS architecture that uses both Cloud DNS
and on-premises DNS servers to provide authoritative DNS resolution. — **Figure 2.** A hybrid DNS architecture that uses both Cloud DNS and on-premises DNS servers provides authoritative DNS resolution.

The scenario shown in figure 2 is the preferred use case. The following details are covered later on this page:

How to set up forwarding between environments using private zones and DNS forwarding.
How to configure firewalls and routing.
Reference architectures that show how to use one or multiple VPC networks.

Keep DNS resolution on-premises

An alternative approach is to continue using your existing on-premises DNS server for authoritatively hosting all internal domain names. In that case, you can use an alternative name server to forward all requests from Google Cloud through outbound DNS forwarding.

This approach has the following advantages:

You make fewer changes in business processes.
You can continue to use your existing tools.
You can use deny lists to filter individual DNS requests on-premises.

However, it has the following disadvantages:

DNS requests from Google Cloud have higher latency.
Your system relies on connectivity to on-premises environments for DNS operations.
You might find it difficult to integrate highly flexible environments such as autoscaled instance groups.
The system might not be compatible with products such as Managed Service for Apache Spark because those products rely on reverse resolution of Google Cloud instance names.

Move all DNS resolution to Cloud DNS

Another approach is to migrate to Cloud DNS as an authoritative service for all domain resolution. You can then use private zones and inbound DNS forwarding to migrate your existing on-premises name resolution to Cloud DNS.

This approach has the following advantages:

You don't need to maintain a high availability DNS service on-premises.
Your system can use Cloud DNS to take advantage of centralized logging and monitoring.

However, it has the following disadvantages:

DNS requests from on-premises have higher latency.
Your system requires a reliable connection to your VPC network for name resolution.

Best practices for Cloud DNS private zones

Private zones host DNS records that are visible only inside your organization. Public zones on Cloud DNS are not covered in this document. Public zones cover the organization's public records, such as DNS records for the public website, and they're not as relevant in a hybrid setup.

Use automation to manage private zones in the Shared VPC host project

If you use Shared VPC networks within your organization, you must host all the private zones on Cloud DNS within the host project. All service projects automatically can access the records in private zones attached to the Shared VPC network. Alternatively, you can set up the zone in a service project using cross-project binding.

Figure 3 shows how private zones are hosted in a Shared VPC network.

Figure 3. Private zones hosted in a Shared VPC network (click to enlarge). — **Figure 3.** This setup shows how private zones are attached to a Shared VPC.

If you want teams to set their own DNS records, we recommend that you automate DNS record creation. For example, you can create a web application or an internal API where users set their own DNS records under specific subdomains. The app verifies that the records comply with your organization rules.

Alternatively, you can put your DNS configuration in a code repository such as Cloud Source Repositories in the form of Terraform or Cloud Deployment Manager descriptors and accept pull requests from teams.

In both cases, a service account with the IAM DNS Administrator role in the host project can automatically deploy the changes after they've been approved.

Set IAM roles using the principle of least privilege

Use the security principle of least privilege to give the right to change DNS records only to those in your organization who need to perform this task. Avoid using basic roles because they might give access to resources beyond those that the user requires. Cloud DNS offers roles and permissions that allow you to give read and write access that is specific to DNS.

If it's important to separate the ability to create private DNS zones from the ability to create public zones, use the dns.networks.bindPrivateDNSZone permission.

Best practices for DNS forwarding zones and server policies

Cloud DNS offers DNS forwarding zones and DNS server policies to allow lookups of DNS names between your on-premises and Google Cloud environment. You have multiple options for configuring DNS forwarding. The following section lists best practices for hybrid DNS setup. These best practices are illustrated in the Reference architectures for hybrid DNS.

Use forwarding zones to query on-premises servers

To make sure that you can query DNS records in your on-premises environment, set up a forwarding zone for the domain that you're using on-premises for your corporate resources (such as corp.example.com). This approach is preferred over using a DNS policy that enables an alternative name server. It preserves access to Compute Engine internal DNS names, and external IP addresses are still resolved without an extra hop through an on-premises name server.

The traffic flow that uses this setup is shown in the Reference architectures for hybrid DNS.

Use alternative name servers only if all DNS traffic needs to be monitored or filtered on-premises, and if private DNS logging can't meet your requirements.

Use DNS server policies to allow queries from on-premises

To allow on-premises hosts to query DNS records that are hosted in Cloud DNS private zones (for example, gcp.example.com), create a DNS server policy using inbound DNS forwarding. Inbound DNS forwarding allows your system to query all private zones in the project as well as internal DNS IP addresses and peered zones.