The following services are offered by gcp for name resolution:
- Internal DNS (169.254.169.254) 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.
Zones
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.

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

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:

Cloud DNS uses the
35.199.192.0/19
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.
Constraints
- 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 35.199.192.0/19 range:

The On-Prem router receives the 35.199.192.0/19 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:

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:

Testing
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:

References
https://cloud.google.com/dns/docs/overview
https://cloud.google.com/dns/docs/best-practices
https://cloud.google.com/dns/docs/best-practices#reference_architectures_for_hybrid_dns