Hybrid Google Cloud DNS Connectivity with Aviatrix

The following services are offered by gcp for name resolution:

  • 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 DNS zone serving.


Cloud DNS supports public and private zones:

Private zones have the following options:

  • forward queries to another server
  • DNS peering
  • Manage reserve lookup zone
  • Use a service directory namespace

Cloud Networking Reference Architecture

The Aviatrix FireNet reference architecture is described below:

Hybrid approach with two authoritative DNS systems

For hybrid environments there are a few options but the recommended option is:

  • 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.
Diagram from https://cloud.google.com/dns/docs/best-practices

A summary of the DNS architecture is:

  • Each spoke VPC network hosts its own private zones
  • DNS peering allow name resolution between environments
  • Custom route advertisement on Cloud Router
Diagram from https://cloud.google.com/dns/docs/best-practices#reference_architectures_for_hybrid_dns

Forwarding zones

A forwarding zone forward requests to targets. Each forwarding target is an IP address of a DNS server, located in your network. There are three types of targets: type 1, type 2, and type 3:

Table from https://cloud.google.com/dns/docs/zones/zones-overview

Cloud DNS uses the source range for all customers. This range is only accessible from a Google Cloud VPC network or from an on-premises network connected to a VPC network.


  • Cloud DNS cannot use transitive routing to connect to a forwarding target.
  • If you are using DNS peering to target a forwarding zone, the target VPC network with the forwarding zone must contain a VM, a VLAN attachment, or a Cloud VPN tunnel located in the same region as the source VM that uses the DNS peering zone.
  • DNS traffic using peering does not transverse Aviatrix network (check my colleague Matt’s post on an alternate way to implement zone forwarding https://encapsulateit.blogspot.com/2022/06/solved-with-aviatrix-google-compute.html)

Routing Configuration

There are two routing methods to choose from when configuring forwarding targets:

  • Standard routing: Routes traffic through an authorized VPC network or over the internet.
  • Private routing: routes traffic through an authorized VPC network, regardless of the target’s IP address (RFC 1918 or not).

To access a Type 1 or a Type 2 forwarding target, Cloud DNS uses routes in the authorized VPC network where the DNS client is located. These routes define a secure path to the forwarding target:

  • Cloud DNS automatically creates subnet routes to send traffic to type 1 targets. To reply, Type 1 targets use a special return route for Cloud DNS responses.
  • Cloud DNS can use either custom dynamic routes or custom static routes to send traffic to type 2 targets.

It doesn’t matter how two VPC are connected. If you have a forwarding target in a second VPC network, create a forwarding zone and authorize that zone for the second network, and then create a peering zone in the first VPC network.

The on-prem connectivity is covered in the following post:

Cloud Router Configuration

We need to create a new custom route for the range:

The On-Prem router receives the prefix and installs on its route table:

If you have connected more than one VPC network to your on-premises network, you must ensure that DNS replies are not sent to the wrong one. Google Cloud discards DNS responses sent to the wrong VPC network.

Peering zones

DNS peering lets you send requests for records that come from one zone’s namespace to another VPC network:

  • The VPC network where the DNS peering zone performs lookups is called the DNS producer network.
  • The VPC network that is authorized to use the peering zone is called the DNS consumer network.

Spoke Configuration

We create private zones on the spokes:

Type A for testing:


Transit Configuration

Forward zone to the on-prem DNS server:

DNS Peering

DNS peer is unidirectional. We need to create two peering:

  • Granting access to the spoke private zone
  • Granting spoke access to the forwarder zone:


From spoke60 instance I lookup for spoke50 instance:

The lookup fails if the DNS peering does not exist.

On-Prem Testing

From spoke50 instance I query web-server.acme.net with success:





Leave a Reply