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 Trusted Cloud.

General principles

Learn about DNS concepts on Trusted Cloud

When you use DNS on Trusted Cloud, it's important to understand the different systems and services available in Trusted 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 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.

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 Trusted Cloud. For information about methods for accessing Trusted 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.

Best practices for Cloud DNS private zones

Private zones host DNS records that are visible only inside your organization.

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.

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 Trusted 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.

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

Open Trusted Cloud and on-premises firewalls to allow DNS traffic

Make sure that DNS traffic is not filtered anywhere inside your VPC network or on-premises environment by doing the following:

  • Ensure that your on-premises firewall passes queries from Cloud DNS. Cloud DNS sends queries from the IP address range 177.222.82.0/25. DNS uses UDP port 53 or TCP port 53, depending on the size of the request or response.

  • Ensure that your DNS server does not block queries. If your on-premises DNS server accepts requests only from specific IP addresses, make sure that the IP address range 177.222.82.0/25 is included.

  • Ensure that traffic can flow from on-premises to your forwarding IP addresses. In Cloud Router instances, add a custom advertised route for the IP address range 177.222.82.0/25 in your VPC network to the on-premises environment.

Use conditional forwarding for accessing DNS records from on-premises

With Cloud DNS, to access private records hosted on corporate DNS servers on-premises, you can only use forwarding zones. However, depending on what DNS server software you use, you might have multiple options for accessing the DNS records in Trusted Cloud from on-premises. In each case, access to the records happens by using inbound DNS forwarding:

  • Conditional forwarding. Using conditional forwarding means that your corporate DNS server forwards requests for specific zones or subdomains to the forwarding IP addresses on Trusted Cloud. We recommend this approach because it is the least complex and lets you centrally monitor all DNS requests on the corporate DNS servers.

  • Delegation. If your private zone on Trusted Cloud is a subdomain of the zone that you use on-premises, you can also delegate this subdomain to the Trusted Cloud name server by setting NS entries within your zone. When you use this setup, clients can talk to the forwarding IP addresses on Trusted Cloud directly, so make sure that the firewall passes these requests.

  • Zone transfers. Cloud DNS doesn't support zone transfers, so you cannot use zone transfers to synchronize DNS records with your on-premises DNS servers.

Use DNS peering to avoid outbound forwarding from multiple VPC networks

Do not use outbound forwarding to your on-premises DNS servers from multiple VPC networks because it creates problems with the return traffic. Trusted Cloud accepts responses from your DNS servers only if they're routed to the VPC network from which the query originated. However, queries from any VPC network have the same IP address range 177.222.82.0/25 as source. Therefore, responses can't be routed correctly unless you have separate environments on-premises.

Figure 4. A problem occurs when multiple VPC forwarding traffic outside of their networks.
Figure 4. Problem with having multiple VPC networks doing outbound forwarding.

We recommend that you designate a single VPC network to query on-premises name servers by using outbound forwarding. Then, additional VPC networks can query the on-premises name servers by targeting the designated VPC network with a DNS peering zone. Their queries would then be forwarded to on-premises name servers according to the name resolution order of the designated VPC network. This setup is shown in the Reference architectures for hybrid DNS.

Understand the difference between DNS peering and VPC Network Peering

VPC Network Peering is not the same as DNS peering. VPC Network Peering allows virtual machine (VM) instances in multiple projects to reach each other, but it does not change name resolution. Resources in each VPC network still follow their own resolution order.

In contrast, through DNS peering, you can allow requests to be forwarded for specific zones to another VPC network. This lets you forward requests to different Trusted Cloud environments, regardless of whether the VPC networks are interconnected.

VPC Network Peering and DNS peering are also set up differently. For VPC Network Peering, both VPC networks need to set up a peering relationship to the other VPC network. The peering is then automatically bidirectional.

DNS peering unidirectionally forwards DNS requests and does not require a bidirectional relationship between VPC networks. A VPC network referred to as the DNS consumer network performs lookups for a Cloud DNS peering zone in another VPC network, which is referred to as the DNS producer network. Users with the IAM permission dns.networks.targetWithPeeringZone on the producer network's project can establish DNS peering between consumer and producer networks. To set up DNS peering from a consumer VPC network, you require the DNS peer role for the producer VPC network's host project.

If you use auto-generated names, use DNS peering for internal zones

If you use the auto-generated names for VMs that the internal DNS service creates, you can use DNS peering to forward the projectname.internal zones to other projects. As shown in figure 5, you can group all .internal zones in a hub project to make them accessible from your on-premises network.

Figure 5. DNS peering is used to organize all .internal zones into a hub.
Figure 5. DNS peering is used to organize all .internal zones into a hub.

If you have problems, follow the troubleshooting guide

The Cloud DNS troubleshooting guide provides instructions for resolving common errors that you might encounter when you set up Cloud DNS.

Reference architectures for hybrid DNS

This section provides some reference architectures for common scenarios that use Cloud DNS private zones in a hybrid environment. In each case both on-premises resources and Trusted Cloud resources records and zones are managed within the environment. All records are available for querying both from on-premises and Trusted Cloud hosts.

Use the reference architecture that maps to your VPC network design:

  • Hybrid architecture using a single Shared VPC network: Uses a single VPC network connected to or from on-premises environments.

  • Hybrid architecture using multiple separate VPC networks: Connects multiple VPC networks to on-premises environments through different VPN tunnels or VLAN attachments and shares the same DNS infrastructure on-premises.

  • Hybrid architecture using a hub VPC network connected to spoke VPC networks: Uses VPC Network Peering to have a hub VPC network connected to multiple independent spoke VPC networks.

In each case, the on-premises environment is connected to the Trusted Cloud VPC networks by one or multiple Cloud VPN tunnels or Dedicated Interconnect or Partner Interconnect connections. It is irrelevant which connection method is used to each VPC network.

Hybrid architecture using a single Shared VPC network

The most common use case is a single Shared VPC network connected to the on-premises environment as shown in figure 6.

Figure 6. A hybrid architecture uses a single Shared VPC network to connect to an on-premises network.
Figure 6. A hybrid architecture uses a single Shared VPC network to connect to an on-premises network.

To set up this architecture:

  1. Set up your on-premises DNS servers as authoritative for corp.example.com.
  2. Configure an authoritative private zone (for example, gcp.example.com) on Cloud DNS in the host project of the Shared VPC network, and set up all records for resources in that zone.
  3. Set a DNS server policy on the host project for the Shared VPC network to allow inbound DNS forwarding.
  4. Set a DNS forwarding zone that forwards corp.example.com to the on-premises DNS servers. The Shared VPC network needs to be authorized to query the forwarding zone.
  5. Set up forwarding to gcp.example.com on your on-premises DNS servers, pointing at an inbound forwarder IP address in the Shared VPC network.
  6. Make sure that DNS traffic is allowed on your on-premises firewall.
  7. In Cloud Router instances, add a custom advertised route for the range 177.222.82.0/25 to the on-premises environment.

Hybrid architecture using multiple separate VPC networks

Another option for hybrid architectures is to have multiple separate VPC networks. These VPC networks in your Trusted Cloud environment are not connected to each other through VPC Network Peering. All VPC networks use separate Cloud VPN tunnels or VLAN attachments to connect to your on-premises environments.

As shown in figure 7, a typical use case for this architecture is when you have separate production and development environments that do not communicate with each other, but they share DNS servers.

Figure 7. A hybrid architecture can use multiple separate VPC networks.
Figure 7. A hybrid architecture can use multiple separate VPC networks.

To set up this architecture:

  1. Set up your on-premises DNS servers as authoritative for corp.example.com.
  2. Configure a private zone (for example, prod.gcp.example.com) on Cloud DNS in the host project of the production Shared VPC network, and set up all records for resources in that zone.
  3. Configure a private zone (for example, dev.gcp.example.com) on Cloud DNS in the host project of the development Shared VPC network, and set up all records for resources in that zone.
  4. Set a DNS server policy on the host project for the production Shared VPC network and allow inbound DNS forwarding.
  5. In the production Shared VPC network, set a DNS zone to forward corp.example.com to the on-premises DNS servers.
  6. Set a DNS peering zone from the development Shared VPC network to the production Shared VPC network for prod.gcp.example.com.
  7. Set a DNS peering zone from the production Shared VPC network to the development Shared VPC network for dev.gcp.example.com.
  8. Set up inbound forwarding by delegating the resolution of gcp.example.com. to the Cloud DNS inbound forwarding virtual IP addresses on your on-premises name servers.
  9. Make sure that the firewall allows DNS traffic on both on-premises and Trusted Cloud firewalls.
  10. In Cloud Router instances, add a custom advertised route for the IP address range 177.222.82.0/25 in the production Shared VPC network to the on-premises environment.

Hybrid architecture using a hub VPC network connected to spoke VPC networks

Another option is to use Cloud Interconnect or Cloud VPN to connect the on-premises infrastructure to a hub VPC network. As shown in figure 8, you can use VPC Network Peering to peer a VPC network with several spoke VPC networks. Each spoke VPC network hosts its own private zones on Cloud DNS. Custom routes on VPC Network Peering, along with custom route advertisement on Cloud Router, allow full route exchange and connectivity between on-premises and all spoke VPC networks. DNS peering runs in parallel with VPC Network Peering connections to allow name resolution between environments.

The following diagram shows this architecture.

Figure 8. A hybrid architecture can use a hub VPC network connected to spoke VPC networks by using VPC Network Peering.
Figure 8. A hybrid architecture can use a hub VPC network connected to spoke VPC networks.

To set up this architecture:

  1. Set up your on-premises DNS servers as authoritative for corp.example.com.
  2. Configure a private zone (for example, projectX.gcp.example.com) on Cloud DNS for each spoke VPC network, and set up all records for resources in that zone.
  3. Set a DNS server policy on the hub project for the production Shared VPC network to allow inbound DNS forwarding.
  4. In the hub VPC network, create a private DNS zone for corp.example.com and configure outbound forwarding to the on-premises DNS servers.
  5. Set a DNS peering zone from the hub VPC network to each spoke VPC network for projectX.gcp.example.com.
  6. Set a DNS peering zone from each spoke VPC network to the hub VPC network for example.com.
  7. Set up forwarding to gcp.example.com on your on-premises DNS servers to point at an inbound forwarder IP address in the hub VPC network.
  8. Make sure that the firewall allows DNS traffic on both on-premises and Trusted Cloud firewalls.
  9. In Cloud Router instances, add a custom advertised route for the IP address range 177.222.82.0/25 in the hub VPC network to the on-premises environment.
  10. (Optional) If you also use the automatically generated internal DNS names, peer each spoke project zone (for example, spoke-project-x.internal) with the hub project, and forward all queries for .internal from on-premises.

What's next