Google Landing Zone: Cloud DNS
In the last blog posts, we discussed various aspects of networking. Now it is time to shift our focus to DNS – another crucial part of a Landing Zone.
For the Google Cloud – Cloud DNS should be used. Google Cloud DNS is a scalable, reliable, and managed authoritative Domain Name System (DNS) service running on the same infrastructure as Google. It offers authoritative DNS serving, which means it provides responses to DNS queries from end-users based on the DNS records you configure.
What are the key features of Cloud DNS?
There are a lot of advantages and features of Google Cloud DNS. Let’s begin with the most important ones:
- Scalability and Reliability: Built on Google’s robust infrastructure, Google Cloud DNS can handle an enormous volume of DNS queries, ensuring that your website or application remains available even under heavy traffic.
- Global Anycast Network: Google Cloud DNS uses anycast routing to ensure that DNS queries are answered from the closest location, improving query response time and reliability.
- Easy Management: With Google Cloud Console, you can easily manage your DNS zones and records. The intuitive interface and REST API make it simple to automate your DNS management tasks.
- Security: Google Cloud DNS supports DNSSEC, a security feature that protects against DNS spoofing and other attacks by ensuring that the responses to DNS queries are authenticated.
- Logging and Monitoring: Google Cloud DNS integrates with Cloud Logging and Cloud Monitoring, providing detailed logs and metrics to help you monitor your DNS traffic and troubleshoot issues.
What kind of DNS zones does Cloud DNS support?
Google Cloud DNS supports several types of DNS zones to cater to different needs and configurations.
1. Public Zones
Public zones are accessible over the internet. They contain DNS records that define how your domain name resolves to IP addresses that are publicly accessible.
- Use Case: Ideal for websites, public-facing APIs, and services that need to be accessible from anywhere on the internet.
- Example: If you own the domain example.com, you can create a public zone that contains records like www.example.com, mail.example.com, etc., which can be accessed by anyone on the internet.
2. Private Zones
Private zones are accessible only from within your Virtual Private Cloud (VPC) network or from specific on-premises locations connected to your Google Cloud network. They contain DNS records that are not exposed to the internet.
- Use Case: Perfect for internal applications, services, and resources that should only be accessible within your internal network.
- Example: You can create a private zone named internal.example.com to manage internal DNS records like database.internal.example.com or app.internal.example.com.
3. Forward Zones
Forward zones in Google Cloud DNS are used to configure DNS forwarding for specific domains. This allows you to direct DNS queries for particular domains to designated DNS servers. This can be particularly useful in hybrid cloud environments where you need to integrate on-premises DNS infrastructure with Google Cloud DNS.
4. Peering Zones
Peering zones in Google Cloud DNS enable DNS resolution between different Virtual Private Cloud (VPC) networks within Google Cloud, without the need for an external DNS server. This feature is particularly useful for organizations managing multiple VPCs that need to share DNS information seamlessly. As such, peering zones allow you to create DNS zones that are shared between VPC networks using VPC Network Peering.
However, keep in mind there are differences between DNS Peering and VPC Peering:
VPC Network Peering:
– Allows VM instances in multiple projects to communicate.
– Does not alter DNS name resolution; each VPC network maintains its own resolution order.
– Requires a bidirectional peering relationship between the VPC networks.
DNS Peering:
– Enables DNS requests for specific zones to be forwarded to another VPC network, facilitating cross-environment name resolution.
– Functions independently of VPC Network Peering.
– Unidirectionally forwards DNS requests, without needing a reciprocal relationship.
– Involves a DNS consumer network performing lookups in a DNS producer network.
– Requires specific IAM permissions to establish and manage DNS peering: `dns.networks.targetWithPeeringZone` for the producer’s project, and the DNS peer role for the producer VPC network’s host project to set up peering from the consumer network.
Managed reverse lookup zones
Managed reverse lookup zones in Google Cloud DNS are used to map IP addresses to domain names. This type of DNS zone is crucial for applications and services that require reverse DNS lookups, such as email servers, network diagnostics, and certain security applications.
DNS Design
After having discussed the various DNS zone types in GCP, let’s now continue to discuss some DNS design.
First of all, it is important to create a simple and consistent naming strategy. This might include the following patterns and choices:
- Disjointed Domain Names: Use separate domains for different environments, such as corp.example.com for on-premises servers and gcp.example.com for Google Cloud resources. This is preferred for ease of forwarding requests between environments. Other public clouds can have separate subdomains.
- Separate Domain Names: Use entirely different domain names like example.com and example.cloud.
- Subdomain Pattern: Make Google Cloud a subdomain of the on-premises domain. For instance, use corp.example.com for on-premises and gcp.corp.example.com for Google Cloud. This is common when most resources are on-premises.
- Reverse Subdomain Pattern: Make the on-premises domain a subdomain of the Google Cloud domain. For example, use corp.example.com for Google Cloud and dc.corp.example.com for on-premises. This is uncommon and suited for digital organizations with minimal on-premises resources.
- Same Domain for Both: Use the same domain for both Google Cloud and on-premises (e.g., corp.example.com). This pattern is generally avoided due to the complexity of managing records in a hybrid environment and is feasible only with a single authoritative DNS system.
The following figure depicts such a simple architecture:
In practice the DNS design will most likely be designed in accordance with your VPC design. In a former blog post, we strongly recommneded a Shared VPC approach. An appropriate DNS design would look like this (from the Google Cloud DNS Archicture page):
1. On-Premises Configuration:
Make your on-premises DNS servers authoritative for `corp.example.com`.
2. Google Cloud Configuration:
Private Zones: Create a private zone (e.g., `projectX.gcp.example.com`) in Cloud DNS for each spoke VPC network and configure all resource records within that zone.
Hub Project: Set a DNS server policy in the hub project for the production Shared VPC network to allow inbound DNS forwarding.
Outbound Forwarding: In the hub VPC network, create a private DNS zone for `corp.example.com` and configure outbound forwarding to the on-premises DNS servers.
DNS Peering:
From the hub VPC network to each spoke VPC network for `projectX.gcp.example.com`.
From each spoke VPC network to the hub VPC network for `example.com`.
3. On-Premises Forwarding:
Set up forwarding on your on-premises DNS servers to `gcp.example.com`, pointing to an inbound forwarder IP address in the hub VPC network.
4. Firewall Configuration:
Ensure DNS traffic is allowed on both on-premises and Google Cloud firewalls.
5. Cloud Router Configuration:
In Cloud Router instances, add a custom route advertisement for the IP range `35.199.192.0/19` in the hub VPC network to the on-premises environment.
6. Optional Configuration:
If using automatically generated internal DNS names, peer each spoke project zone (e.g., `spoke-project-x.internal`) with the hub project and forward all `.internal` queries from on-premises.
> Click here for Part 10: Automation
