Expanding Private DNS Resolution in a Hybrid Environment with Google Cloud Platform (GCP)

Published in

Google Cloud - Community

7 min readMay 28, 2023

More and more organizations are gravitating towards hybrid environments primarily due to security concerns, or simply because transferring all their existing workloads to the cloud can take years. For those utilizing the Google Cloud Platform (GCP), a key query when initiating their cloud journey is how to transition their applications seamlessly without disrupting their current workloads. In this context, several services become critical, and among them, Cloud DNS stands out. It plays a crucial role, especially when it comes to expanding and resolving DNS within a hybrid environment.

What Expending Private DNS Resolution is ?

In a hybrid environment, where you have some resources on-premises and others in the cloud, it’s crucial that the DNS can resolve names for all resources, regardless of where they are located. In this context, expanding DNS resolution refers to extending the capability of the Domain Name System (DNS) so that it can resolve names across different environments.

Why Expending Private DNS Resolution ?

In a hybrid environment, the need to resolve private DNS records from both on-premises and spoke networks is paramount for a couple of reasons.

First, it’s about ensuring seamless communication between various services and applications. By resolving DNS records, services can communicate using human-friendly domain names instead of relying on IP addresses, which are harder to remember and manage. This allows a mobile e-commerce platform, for example, to migrate its core applications to GCP’s Google Kubernetes Engine (GKE), while retaining its back-office applications on-premises, without losing any connectivity or facing any service-level communication issues.

Second, it’s about security. Resolving private DNS records ensures that internal communication remains within the private network, minimizing exposure to external threats. This is critical in a hybrid setup where applications on the cloud and those on-premises need to interact securely, such as in environments with multiple VPCs in different projects.

How Expending Private DNS Resolution ?

Google Cloud offers two key features to facilitate DNS resolution in a hybrid environment: DNS Peering and DNS Forwarding. Both play crucial roles in maintaining operational efficiency and security in a hybrid setup.

DNS Peering

DNS Peering is used when you want to connect two VPC networks, allowing them to share DNS information. This is especially useful when you have different environments such as development, staging, and production, each in separate projects with their own VPC. By creating a DNS peering connection from the dev and stage VPCs to the prod VPC, the separate networks can discover and communicate with each other using DNS names.

Peering, however, forwards DNS requests in a unidirectional manner. Therefore, for a complete network setup where all networks should discover anything and everything within the entire setup, a DNS peering zone should be created in all projects, allowing them to become both consumers and producers of DNS information.

DNS Forwarding

DNS Forwarding, on the other hand, is used when DNS queries from a VPC network need to be forwarded to another server (typically a DNS server in an on-premises network or a different VPC). This allows a VPC network to access DNS data that it doesn’t have locally, promoting interconnectivity between different environments.

For instance, you could create a DNS forwarding zone in a GCP project for an on-premises domain. This forwarding zone does not allow the addition of records, as it retrieves data from your on-premises DNS, ensuring that DNS queries are properly resolved even if they are for domains hosted on-premises.

Lab Design

In this section, we will delve into a real-world scenario where we set up a hub-spoke network topology on GCP, with one spoke network and an additional on-premises network. The hub and spoke networks will be connected using VPC Network Peering, and the on-premises network will be connected to the hub via a VPN connection. We will add two DNS zones in this setup, one located in the hub and the other on-premises. A DNS peering connection will be established between the hub and spoke VPN, allowing for seamless DNS resolution between the two. Additionally, we will set up bidirectional forwarding between the hub and the on-premises setup using DNS forwarding, ensuring consistent DNS data across both environments.

How to build this design ?

In this section, we are going to deep dive into the procedure involved in constructing our desired design. We will unfold this process step by step, elaborating on each aspect in detail to provide a comprehensive understanding of how to achieve our target design.

Step 0: We will start with setting the necessary env variables, this will facilitate installation steps

export PROJECT_ID="your-project-id"
export REGION="your-region" # ex: europe-west3

export HUB_NETWORK_NAME="hub-network"
export HUB_SUBNET_NAME="hub-subnet"

export SPOKE_NETWORK_NAME="spoke-network"
export SPOKE_SUBNET_NAME="spoke-subnet"

export ONPREM_NETWORK_NAME="onprem-network"
export ONPREM_SUBNET_NAME="onprem-subnet"

export VPN_SHARED_SECRET="your-secret-vpn"

Step 1: To establish a the hybrid hub-spoke typologie, you’ll need to create hub and spoke networks and a third network to simulate the on-premises environment. Ensure that the hub and spoke are interconnected using peering. Additionally, to establish a connection between the hub and the on-premise network, a VPN utilizing Border Gateway Protocol (BGP) is necessary. For a step-by-step guide on how to implement this setup, please refer to the detailed instructions in the main body of this article :

Example of Hybrid Hub-Spoke Network Topology on Google Cloud Platform (GCP)

Increasingly, organizations are adopting the Hub-Spoke Network Architecture due to its manageability and scalability…

medium.com

Step 2: Attached to hub network, we’ll establish a private zone dubbed “cloud.local”.

# Create private dns zone "cloud.local"
gcloud dns managed-zones create cloud-local-zone \
   --dns-name="cloud.local." \
   --description="Cloud local DNS Zone" \
   --networks $HUB_NETWORK_NAME \
   --visibility private

Step 3: Attached to spoke network, proceed to add a peering DNS zone for the domain “cloud.local”.

# Create peering dns zone "cloud.local"
gcloud dns managed-zones create cloud-peering-zone \
   --dns-name="cloud.local." \
   --description="Cloud local DNS Zone" \
   --networks $SPOKE_NETWORK_NAME \
   --target-project $PROJECT_ID \
   --target-network=$HUB_NETWORK_NAME \
   --visibility private

Step 4: Attached to on-premise network, we’ll establish a private zone dubbed “site.local”.

# Create private dns zone "site.local"
gcloud dns managed-zones create onprem-local-zone \
   --dns-name="site.local." \
   --description="Site local DNS Zone" \
   --networks $ONPREM_NETWORK_NAME \
   --visibility private

Step 5: We will link to the hub and set up a forwarding DNS zone for “site.local”. Similarly, we need to establish outbound forwarding zones associated with “cloud.local”.

# Create outbound forwarding dns zone "site.local"
gcloud dns managed-zones create site-forwarding-zone \
   --dns-name="site.local." \
   --description="Site forwarding DNS Zone" \
   --networks $HUB_NETWORK_NAME \
   --forwarding-targets=35.199.192.1 \
   --visibility private

# Create outbound forwarding dns zone "cloud.local"
gcloud dns managed-zones create cloud-forwarding-zone \
   --dns-name="cloud.local." \
   --description="Cloud forwarding DNS Zone" \
   --networks $ONPREM_NETWORK_NAME \
   --forwarding-targets=35.199.192.2 \
   --visibility private

Test and validate this design ?

Testing and validation of our design are critical steps. To accomplish this, a virtual machine (VM) can be installed within the each network, acting as a representative client for the network’s endpoints. By utilizing the ‘nslookup’ command, it is possible to check if a DNS record is resolved.

Step 1: Create the three virtual machines within our networks

# Client machine for HUB
gcloud compute instances create hub-vm \
    --project=$PROJECT_ID \
    --zone=${REGION}-a \
    --machine-type=e2-medium \
    --network=$HUB_NETWORK_NAME \
    --subnet=$HUB_SUBNET_NAME \
    --tags client-vm --metadata enable-oslogin=TRUE

# Client machine for Spoke
gcloud compute instances create spoke-vm \
    --project=$PROJECT_ID \
    --zone=${REGION}-a \
    --machine-type=e2-medium \
    --network=$SPOKE_NETWORK_NAME \
    --subnet=$SPOKE_SUBNET_NAME \
    --tags client-vm --metadata enable-oslogin=TRUE

# Client machine for On-premise
gcloud compute instances create onprem-vm \
    --project=$PROJECT_ID \
    --zone=${REGION}-a \
    --machine-type=e2-medium \
    --network=$ONPREM_NETWORK_NAME \
    --subnet=$ONPREM_SUBNET_NAME \
    --tags client-vm --metadata enable-oslogin=TRUE

Step 2: At this point, it is necessary to create a DNS A record “test.cloud.local” within the “cloud-local-zone” DNS zone, as well as “test.site.cloud” in the “site-local-zone” DNS zone.

# Create test.cloud.local record
#create new record description as YAML file
cat > test-cloud-record.yml <<EOF
kind: dns#resourceRecordSet
name: test.cloud.local.
rrdatas:
- 10.0.0.10
ttl: 300
type: A
EOF

#Import the record
gcloud dns record-sets import -z=cloud-local-zone \
   --delete-all-existing test-cloud-record.yml

# Create test.site.local record
#create new record description as YAML file
cat > test-site-record.yml <<EOF
kind: dns#resourceRecordSet
name: test.site.local.
rrdatas:
- 10.1.0.10
ttl: 300
type: A
EOF

#Finally, you need to import the record
gcloud dns record-sets import -z=site-local-zone \
   --delete-all-existing test-site-record.yml

Step 3: Finally, connect to each vm an validate that your DNS resolution is working fine. You can run the following commands :

# Install dnsutils package
sudo apt install dnsutils

# Run test
nslookup test.cloud.local
nslookup test.site.local

Conclusion

The process of expanding DNS in a hybrid environment involves multiple considerations, such as the need to resolve private DNS records from both on-premises and spoke networks. With Google Cloud’s DNS Peering and DNS Forwarding features, organizations can ensure effective DNS resolution across different environments, promoting secure and seamless communication in a hybrid setup. As always, the choice between peering and forwarding depends on the specific use case, but both offer robust solutions to common DNS challenges in hybrid environments.

Originally published at https://hassene.belgacem.io .