DNS Best practices

This document provides best practices for:

Introduction

It's easier for both humans and applications to address applications and services using the Domain Name System (DNS), 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 using an authoritative DNS server, such as BIND in UNIX/Linux environments or Active Directory in Microsoft Windows environments. This article describes best practices for how to forward private DNS requests between environments to make sure 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. For details, see Cloud DNS overview.
  • 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.
  • Google Domains is a domain registrar for buying, transferring, or managing domains. This is a Google service that's not part of Google Cloud.

Identify stakeholders, tools, and processes

When you think about building a strategy for DNS in a hybrid environment, it's important to first familiarize yourself with your current architecture and make contact with 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 in order to map your on-premises configuration to a suitable architecture on Google Cloud. For details, see Use conditional forwarding for accessing DNS records from on-premises on methods for accessing Google Cloud DNS records.
  • 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 multi-cloud patterns and practices.

Create a simple, consistent naming standard

Create a naming standard that is consistent throughout your organization but simple to remember. For example, assume 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:

  • Have disjoint 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 it's easy to forward requests between environments.

    You can also use completely separate domain names such as example.com and example.cloud.

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

  • 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 native organizations that have only a small footprint on-premises.

  • Use the same domain for Google Cloud and for on-premises. In this case, both Google Cloud and on-premises use resources using the corp.example.com domain. You should 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 hosting records for your Google Cloud resources.

The following diagram shows this arrangement:

Example domain name setup (click to enlarge)
Example domain name setup (click to enlarge)

For naming resources within your VPC network, you can follow guidelines such as the ones in 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:

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

The following diagram shows this arrangement:

Hybrid architecture with two authoritative DNS systems (click to enlarge)
Hybrid architecture with two authoritative DNS systems (click to enlarge)

This scenario is the preferred use case and is covered in detail in this document. The document covers the following:

  • 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 VPCs.

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 forward all requests from Google Cloud through outbound DNS forwarding using an alternative name server. This approach has the following advantages:

  • You make fewer changes in business processes.
  • You can continue to use your existing tools.
  • Individual DNS requests can be filtered on-premises using deny lists.

However, it has the following disadvantages:

  • DNS requests from Google Cloud have higher latency.
  • Your system relies on connectivity to on-premises 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 Cloud Dataproc, 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 migrate your existing on-premises name resolution to Cloud DNS using private zones and inbound DNS forwarding. This approach has the following advantages:

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

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 allow teams 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.

The following diagram shows how private zones are hosted in a Shared VPC network:

Private zones hosted in a shared VPC network (click to enlarge)
Private zones hosted in a shared VPC network (click to enlarge)

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 DNS Admin IAM role in the host project can automatically deploy the changes after they've been approved.

Set IAM roles using the principle of least privilege

Using the security principle of least privilege , give the right to change DNS records only to those in your organization who need to perform this task. Avoid using primitive roles, because they might give access to resources beyond those that the user requires. Cloud DNS offers permissions and roles that allow you to give read and write access that is specific to just 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

Cloud DNS offers DNS server policies and DNS forwarding zones 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.

DNS forwarding cannot be used to forward between different Google Cloud environments, regardless of which way they are interconnected. For that use case, use DNS peering.

Use forwarding zones to query on-premises servers

To make sure 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 public IP addresses are still resolved without an additional hop through an on-premises nameserver.

The traffic flow using this setup is shown in the reference architectures.

You should use alternative name servers only if all DNS traffic needs to be monitored or filtered on-premises, and if your requirements can't be met by private DNS logging.

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 addresses and peered zones. Although you have a separate inbound forwarder IP address for each subnet, all DNS queries return identical responses and there is no latency difference. Your apps can send a request to any of those addresses.

The traffic flow using this setup is shown in the reference architectures.

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

Make sure DNS traffic is not filtered anywhere inside your VPC or on-premises. This includes:

  • Make sure your on-premises firewall passes queries from Cloud DNS. Cloud DNS sends queries from the 35.199.192.0/19 IP address range. DNS uses UDP port 53 or TCP port 53, depending on the size of the request or response.

  • Make sure your DNS server does not block queries. If your on-premises DNS server accepts requests only from specific IP addresses, make sure the range 35.199.192.0/19 is included.

  • Make sure traffic can flow from on-premises to your forwarding IP addresses. For inbound forwarding, make sure traffic flowing to the forwarding IP addresses from your on-premises DNS servers or other clients is not blocked by your on-premises firewall. You might have to create a firewall rule on your on-premises firewall to allow traffic from all clients on UDP port 53 to the forwarding IP address.

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 Google Cloud from on-premises. In each case, access to the records happens 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 Google Cloud. We recommend this approach, because it is the least complex and allows you to centrally monitor all DNS requests on the corporate DNS servers.

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

  • Zone transfers: Cloud DNS doesn't support zone transfers, so you cannot synchronize DNS records with your on-premises DNS servers using zone transfers. You can then use your on-premises DNS servers as an authoritative source for Cloud DNS records. This reduces the need for a stable connection for name resolution, but it comes at the risk of serving stale records if the zone is not re-synced on each change.

Use DNS peering to avoid outbound forwarding from multiple VPCs

You must not use outbound forwarding to your on-premises DNS servers from multiple VPC networks, because it creates problems with the return traffic. Responses from your DNS servers are accepted by GCP only if they're routed to the VPC from which the query originated. However, queries from any VPC have the same 35.199.192.0/19 IP range as source. Therefore, responses can't be routed correctly unless you have completely separate environments on-premises.

The following diagram illustrates the problem with having multiple VPCs doing outbound forwarding:

Issues with multiple VPCs doing outbound forwarding (click to enlarge)
Issues with multiple VPCs doing outbound forwarding (click to enlarge)

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

Understand the difference between DNS peering and VPC Network Peering

VPC Network Peering is not the same as DNS peering. VPC Network Peering allows VMs in multiple projects to reach each other, but it does not change name resolution. Resources in each VPC still follow their own resolution order. In contrast, through DNS peering, you can allow requests to be forwarded for specific zones to another VPC. This allows you to forward requests to different Google Cloud environments, regardless of whether the VPCs are interconnected.

VPC Network Peering and DNS peering are also set up differently. For VPC Network peering, both VPCs need to set up a peering relationship to the other VPC. The peering is then automatically bi-directional.

DNS peering unidirectionally forwards DNS requests and does not require a bi-directional relationship between VPCs. 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 Cloud 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 are created by the internal DNS service, you can use DNS peering to forward the projectname.internal zones to other projects. You can aggregate all .internal zones in a hub project to make them all available from on-premises. However, DNS peering is non-transitive, so if you have multiple projects that want to use each other's internal DNS, you have to set up DNS peering in a mesh between all of them.

This mesh setup is shown in the following diagram:

DNS peering in a mesh setup (click to enlarge)
DNS peering in a mesh setup (click to enlarge)

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 using Cloud DNS private zones in a hybrid environment. In each case both on-premises resources and Google Cloud resources records and zones are managed within the environment. All records are available for querying both from on-premises and Google Cloud hosts.

You should use the reference architecture which maps to your VPC design:

  • Hybrid architecture using a single shared VPC - using a single VPC network connected to/from on-premises

  • Hybrid architecture using multiple separate VPC networks - if you connect multiple VPCs to on premises via different VPN tunnels or VLAN attachments but share the same DNS infrastructure on-premises

  • Hybrid architecture using a hub VPC network connected to spoke VPC networks - if you use 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 Google Cloud VPCs via one or multiple Cloud VPN tunnels or Cloud Interconnect - Dedicated or Partner connections. It is irrelevant which connection method is used to each VPC network.

Hybrid architecture using a single Shared VPC network

The most common case is a single Shared VPC network connected to the on-premises environment and is shown in the following diagram:

Hybrid architecture using a single shared VPC network (click to enlarge)
Hybrid architecture using a single shared VPC network (click to enlarge)

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 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 custom route advertisement for range 35.199.192.0/19 to on-premises.

Hybrid architecture using multiple separate VPC networks

Another option for hybrid architectures is to have multiple separate VPC networks. These VPC networks in your Google Cloud environment are not connected to each other through VPC Network Peering. All VPC networks are connected to your on-premises environments using separate Cloud VPN tunnels or VLAN attachments. A typical use case for this architecture is when you have separate environments that do not communicate with each other, but they share DNS servers. A typical use case is having separate production and development environments.

This architecture is shown in the following diagram:

Hybrid architecture using multiple separate VPC networks (click to enlarge)
Hybrid architecture using multiple separate VPC networks (click to enlarge)

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 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 forwarding to gcp.example.com on your on-premises DNS servers, pointing at an inbound forwarder IP in the production Shared VPC network.
  9. Make sure that the firewall allows DNS traffic on both on-premises and Google Cloud firewalls.
  10. In Cloud Router instances, add custom route advertisement for the range 35.199.192.0/19 in the production Shared VPC network to on-premises.

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

Another option is to connect the on-premises infrastructure to a single hub VPC network using Cloud Interconnect or Cloud VPN. You peer this VPC Network with several spoke VPC networks using VPC Network Peering. 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 connection to allow name resolution between environments.

This architecture is depicted in the following diagram:

Hybrid architecture using a hub VPC networks connected to spoke
         VPC networks (click to enlarge)
Hybrid architecture using a hub VPC networks connected to spoke VPC networks (click to enlarge)

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 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, 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 to each spoke VPC for projectX.gcp.example.com.
  6. Set a DNS peering zone from each spoke VPC to the hub VPC 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.
  8. Make sure that the firewall allows DNS traffic on both on-premises and Google Cloud firewalls.
  9. In Cloud Router instances, add custom route advertisement for the range 35.199.192.0/19 in the hub VPC to on-premises.
  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.

Next Steps

Oliko tästä sivusta apua? Kerro mielipiteesi

Palautteen aihe:

Tämä sivu
Cloud DNS Documentation