Cloud DNS

Cloud DNS is a high performance, resilient, global, fully-managed DNS service that provides a RESTful API to publish and manage DNS records for your applications and services.

Google Cloud DNS – Managed Authoritative DNS

~ Last updated on : ~ jayendrapatil

Google Cloud DNS

  • Cloud DNS is a high-performance, resilient, reliable, low-latency, global Domain Name System (DNS) service that publishes the domain names to the global DNS in a cost-effective way.
  • Cloud DNS helps to publish the zones and records in DNS without the burden of managing your own DNS servers and software.
  • Cloud DNS offers both public zones and private managed DNS zones.
    • A public zone is visible to the public internet
    • A private zone is visible only from one or more specified VPC networks
    • Google Cloud also creates internal DNS names for VMs automatically, even if you do not use Cloud DNS
  • Cloud DNS also supports zonal DNS zones (GA since Dec 2022) that are scoped to a specific Google Cloud zone, providing higher availability for zonal resources.
  • With Shared VPC, Cloud DNS managed private zone, Cloud DNS peering zone, or Cloud DNS forwarding zone must be created in the host project
  • Google Cloud offers inbound and outbound DNS forwarding for private zones
  • Cloud DNS offers DNS forwarding zones and DNS server policies to allow lookups of DNS names between the on-premises and Google Cloud environment
  • Cloud DNS supports per-resource IAM permissions (GA since Dec 2022) allowing fine-grained read, write, or administrator permissions for different managed zones under the same project.
  • Cloud DNS supports Cloud Logging for both private and public zones (GA since Nov 2021) to monitor DNS queries, including query name, type, response code, and source IP address.

DNS Server Policies

  • DNS Server Policies can specify inbound DNS forwarding, outbound DNS forwarding, or both.
  • Inbound server policy refers to a policy that permits inbound DNS forwarding i.e. On-premises to VPC
  • Outbound server policy refers to one possible method for implementing outbound DNS forwarding i.e. VPC to On-premises
  • It is possible for a policy to be both an inbound server policy and an outbound server policy if it implements the features of both.
  • DNS Server Policies is similar to DNS Forwarding zones, except that it applies to all the traffic and not a single specific domain
  • DNS Outbound Policy disables internal DNS for the selected networks
  • DNS Server Policies also support DNS64 configuration to enable IPv6-only VM instances to communicate with IPv4-only destinations (see DNS64 section below).

DNS Forwarding Zones

  • Cloud DNS forwarding zones help configure target name servers for specific private zones.
  • Using a forwarding zone is one way to implement outbound DNS forwarding from the VPC network.
  • A Cloud DNS forwarding zone is a special type of Cloud DNS private zone. Instead of creating records within the zone, you specify a set of forwarding targets.
  • Each forwarding target is an IP address of a DNS server, located in the VPC network, or in an on-premises network connected to the VPC network by Cloud VPN or Cloud Interconnect.
  • Forwarding targets can also be specified as a fully qualified domain name (FQDN) (GA since June 2025), which allows outbound DNS forwarding without requiring a fixed IP address for the target name server.
  • Cloud DNS caches responses for queries sent to Cloud DNS forwarding zones
  • DNS forwarding does not work between two Google Cloud environments

DNS Peering

  • DNS peering allows sending requests for records that come from one zone’s namespace to another VPC network for e.g., a SaaS provider can give a SaaS customer access to DNS records it manages.
  • To provide DNS peering,
    • Cloud DNS peering zone must be created and configured to perform DNS lookups in a VPC network where the records for that zone’s namespace are available.
    • The VPC network where the DNS peering zone performs lookups is called the DNS producer network.
  • To use DNS peering,
    • A network must be authorized to use a peering zone.
    • The VPC network authorized to use the peering zone is called the DNS consumer network.
  • DNS peering and VPC Network Peering are different services. DNS peering can be used with VPC Network Peering, but VPC Network Peering is NOT required for DNS peering. VPC peering does not enable DNS peering and must be setup explicitly.

Cloud DNS Forwarding and Peering

DNS Routing Policies

  • Cloud DNS supports DNS routing policies (GA since Jan 2022) to steer traffic based on specific criteria for resource record sets in both private and public zones.
  • Cloud DNS supports the following routing policy types:
    • Weighted Round Robin (WRR) – assign different weights to each resource record set for a DNS name to distribute traffic according to configured weights. Supports manual active-active or active-passive configurations.
    • Geolocation – map traffic originating from source geographies (Google Cloud regions) to specific DNS targets. Applies nearest match when source doesn’t exactly match a policy item.
    • Geolocation with Geofence – restricts traffic to a specific geolocation even if all endpoints in that region are unhealthy (prevents automatic failover to next closest region).
    • Failover – active/backup configurations for high availability. Returns IP addresses from the active set normally; switches to backup set when all active endpoints are unhealthy.
  • DNS routing policies cannot be configured for forwarding zones, peering zones, managed reverse lookup zones, or Service Directory zones.
  • Cloud DNS supports health checks with routing policies for:
    • Internal Application Load Balancers (regional and cross-region)
    • Internal passthrough Network Load Balancers
    • Internal proxy Network Load Balancers (Preview)
    • External endpoints (GA since Feb 2025) – health checks for any public IP address including global/regional external load balancers and on-premises endpoints
  • Cloud DNS enables automatic failover when endpoints fail their health checks, dynamically adjusting traffic split among remaining healthy endpoints.
  • For external endpoint health checks, probes originate from three user-specified Google Cloud source regions with three prober instances per region (nine total probers per endpoint).
  • If all endpoints are unhealthy, Cloud DNS returns all endpoints as a result (fail-open behavior).

DNS Response Policies

  • Response policies (GA since Nov 2021) let you customize DNS management within a private zone by using rules instead of records.
  • If a rule in the response policy affects the incoming query, it is processed; otherwise, the lookup proceeds normally.
  • Response policy rules are selectors that apply behavior to queries matching the selector (DNS names via wildcards or exact matches).
  • Use cases include:
    • Setting up private connectivity to Google APIs from within a VPC Service Controls perimeter
    • Overriding DNS resolution for specific domains within a VPC network
    • Blocking access to specific domains by returning NXDOMAIN
    • Redirecting traffic to alternative endpoints for specific DNS names
  • Response policies can be bound to VPC networks and GKE clusters.

Alias Records

  • Alias records (GA since Sept 2025) provide CNAME-like functionality at the zone apex.
  • This custom record type maps the apex domain name to a canonical target, solving the limitation that CNAME records cannot coexist with other record types (like SOA) required at the zone apex.
  • Useful when you need to point a naked/apex domain (e.g., example.com) to a load balancer or CDN hostname without using a CNAME.
  • Similar in concept to AWS Route 53 Alias records.

DNS64

  • DNS64 (GA since Aug 2025) provides synthesized IPv6 addresses for IPv4 destinations, enabling IPv6-only VM instances to communicate with IPv4-only services.
  • DNS64 is configured as part of a DNS server policy and applies to VPC networks bound to the policy.
  • When an IPv6-only client queries for a domain that only has A records (IPv4), Cloud DNS synthesizes AAAA records (IPv6) using the 64:ff9b::/96 well-known prefix.
  • Works together with Cloud NAT’s NAT64 to provide end-to-end IPv6-to-IPv4 connectivity.
  • Useful for IPv6-only environments that need to reach legacy IPv4 applications on the internet.

DNS Armor – Advanced Threat Detection

  • DNS Armor (GA since Jan 2026), powered by Infoblox, is a fully-managed DNS-layer security service for Google Cloud workloads.
  • Monitors internet-bound DNS queries for malicious activity at the earliest point in the attack chain—the DNS query—without adding operational complexity or performance overhead.
  • Detects threats including:
    • Requests to malicious command and control (C2) servers
    • DNS tunneling for sensitive data exfiltration
    • Malware using DNS queries for communication
  • Complements existing cloud-first network security products (Cloud Armor, Cloud NGFW) by offering a foundational DNS-based security layer.
  • Threat findings are reported in Cloud Logging for integration with security operations workflows.

VPC Name Resolution Order

  • Each VPC network provides DNS name resolution services to the VM instances that use it.
  • When VMs use their metadata server 169.254.169.254 as their name server, Google Cloud searches for DNS records in the following order:
    • If the VPC network has an outbound server policy, Google Cloud forwards all DNS queries to those alternative servers. The VPC name resolution order consists only of this step.
    • If the VPC network does not have an outbound server policy:
      • Google Cloud tries to find a private zone that matches as much of the requested record as possible (longest suffix matching).
        • Searching records that you created in private zones.
        • Querying the forwarding targets for forwarding zones.
        • Querying the name resolution order of another VPC network by using peering zones.
      • Searches the automatically created Compute Engine internal DNS records for the project.
      • Queries publicly available zones

DNSSEC

  • DNSSEC is a feature of DNS that authenticates responses to domain name lookups
  • DNSSEC protects the domains from spoofing and cache poisoning attacks
  • DNSSEC provides strong authentication for domain lookups, but it does not provide encryption
  • Both the registrar and registry must support DNSSEC for the Top Level Domain (TLD) used
  • For Enabling DNSSEC
    • Enable DNSSEC on the domain. DNS zone for the domain must serve special DNSSEC records for public keys (DNSKEY), signatures (RRSIG), and non-existence (NSEC, or NSEC3 and NSEC3PARAM) to authenticate the zone’s contents.
    • DS record must be added to the TLD at the registrar
    • DNS resolver that validates signatures for DNSSEC-signed domains must be used
  • Note: When DNSSEC is enabled with DNS routing policies, only a single IP address can be used within each policy item.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

Questions on DNS Routing Policies and New Features

  1. A company needs to distribute DNS traffic across multiple regions with automatic failover when a region becomes unhealthy. Which Cloud DNS routing policy should they use?
    1. Weighted Round Robin (WRR) routing policy
    2. Geolocation routing policy
    3. Failover routing policy
    4. DNS forwarding policy
    Show Answer

    Answer: b. Geolocation routing policy – Geolocation routing with health checks automatically fails over to the next closest region when endpoints are unhealthy. Failover routing policy (c) provides active/backup, not multi-region distribution.

  1. A company wants to point their apex domain (example.com) to a load balancer hostname without using an A record with a static IP. What Cloud DNS feature should they use?
    1. CNAME record at the apex
    2. DNS peering zone
    3. Alias record
    4. DNS forwarding zone
    Show Answer

    Answer: c. Alias record – Alias records (GA Sept 2025) provide CNAME-like functionality at the zone apex. CNAME records cannot be placed at the apex because they cannot coexist with SOA records.

  1. An organization has IPv6-only VM instances that need to access legacy IPv4-only services on the internet. Which combination of features should they configure?
    1. Cloud NAT with DNS forwarding
    2. DNS64 with NAT64
    3. DNS peering with Cloud VPN
    4. DNSSEC with IPv6 forwarding
    Show Answer

    Answer: b. DNS64 with NAT64 – DNS64 synthesizes AAAA records from A records using the 64:ff9b::/96 prefix, and NAT64 handles the actual packet translation, enabling IPv6-only VMs to reach IPv4 destinations.

  1. A security team wants to detect DNS-based command and control (C2) communication and data exfiltration from their Google Cloud workloads. Which service should they enable?
    1. DNSSEC
    2. Cloud Armor
    3. DNS Armor
    4. DNS Response Policies
    Show Answer

    Answer: c. DNS Armor – DNS Armor (GA Jan 2026), powered by Infoblox, provides DNS-layer threat detection for C2 communications, DNS tunneling, and malware DNS queries.

  1. Which of the following routing policy types restricts DNS traffic to a specific geolocation even when all endpoints in that region are unhealthy?
    1. Weighted Round Robin (WRR)
    2. Geolocation routing policy
    3. Geolocation routing policy with geofence
    4. Failover routing policy
    Show Answer

    Answer: c. Geolocation routing policy with geofence – With geofencing enabled, automatic failover to the next closest region does not occur, even if all endpoints in a geolocation fail health checks.

  1. An organization wants to override DNS resolution for specific Google API domains within their VPC to route to VPC Service Controls restricted endpoints. What Cloud DNS feature should they use?
    1. DNS forwarding zone
    2. DNS server policy
    3. DNS response policy
    4. DNS peering zone
    Show Answer

    Answer: c. DNS response policy – Response policies allow custom DNS resolution within VPCs, making it easy to route specific API domains to restricted VIPs for VPC Service Controls compliance.

  1. Cloud DNS health checks for external endpoints (GA Feb 2025) support which of the following? (Choose 2)
    1. Health checking endpoints behind Cloud VPN
    2. TCP, HTTP, and HTTPS protocols
    3. Health check probes from three user-specified regions
    4. gRPC protocol health checks
    5. Probes from fixed IP address ranges
    Show Answer

    Answer: b, c – External endpoint health checks support TCP/HTTP/HTTPS protocols and originate from three user-specified source regions. gRPC, SSL, and HTTP/2 are not supported. Probe source IP ranges are not fixed.

References

Google Cloud Networking Services Cheat Sheet

~ Last updated on : ~ jayendrapatil

Virtual Private Cloud

  • Virtual Private Cloud (VPC) provides networking functionality for the cloud-based resources and services that is global, scalable, and flexible.
  • VPC networks are global resources, including the associated routes and firewall rules, and are not associated with any particular region or zone.
  • Subnets are regional resources and each subnet defines a range of IP addresses
  • IPv6 Support
    • VPC networks support dual-stack (IPv4 and IPv6) subnets in custom-mode VPC networks.
    • IPv6 functionality is available only in Premium Tier.
    • Supports both external (GUA – Globally Unique Addresses) and internal (ULA – Unique Local Addresses) IPv6 ranges.
    • VMs can have IPv4-only, dual-stack, or IPv6-only interfaces.
  • Cloud NGFW (Next Generation Firewall)
    • replaces legacy VPC firewall rules with network firewall policies.
    • protects workloads by applying controls at Layer 3, Layer 4, and Layer 7 of the network stack.
    • available in three tiers:
      • Essentials – rules based on IP ranges, ports, and protocols
      • Standard – adds FQDN objects, geo-location objects, and threat intelligence
      • Enterprise – adds Intrusion Detection and Prevention Service (IPS) powered by Palo Alto Networks, TLS inspection
    • Google recommends migrating from legacy VPC firewall rules to Cloud NGFW network firewall policies.
    • Network firewall policies can be attached to a single VPC or group of VPCs (unlike legacy VPC firewall rules which apply to a single VPC only).
  • Resources within a VPC network can communicate with one another by using internal IPv4 addresses, subject to applicable network firewall rules.
  • Private access options for services allow instances with internal IP addresses to communicate with Google APIs and services.
  • Private Service Connect (PSC)
    • allows consumers to access managed services privately from inside their VPC network.
    • allows managed service producers to host services in their own separate VPC networks and offer a private connection to consumers.
    • creates service endpoints in consumer VPCs that provide private connectivity and policy enforcement.
  • Shared VPC to keep a VPC network in a common host project shared with service projects. Authorized IAM members from other projects in the same organization can create resources that use subnets of the Shared VPC network
  • VPC Network Peering allows VPC networks to be connected with other VPC networks in different projects or organizations.
  • VPC networks can be securely connected in hybrid environments by using Cloud VPN or Cloud Interconnect.
  • Primary and Secondary IP address cannot overlap with the on-premises CIDR
  • VPC Flow Logs records a sample of network flows sent from and received by VM instances, including instances used as GKE nodes.

Cloud Load Balancing

  • Cloud Load Balancing is a fully distributed, software-defined managed load balancing service
  • distributes user traffic across multiple instances of the applications and reduces the risk of performance issues by spreading the load
  • provides health checking mechanisms that determine if backends, such as instance groups and zonal network endpoint groups (NEGs), are healthy and properly respond to traffic.
  • supports IPv6 clients with Application Load Balancers and proxy Network Load Balancers.
  • Note: Google Cloud has renamed load balancer types. HTTP(S) Load Balancing is now Application Load Balancer, TCP/UDP Load Balancing is now passthrough Network Load Balancer, and SSL Proxy/TCP Proxy are now proxy Network Load Balancer.
  • supports multiple Cloud Load Balancing types
    • Internal Application Load Balancer (formerly Internal HTTP(S) Load Balancing)
      • is a proxy-based, regional Layer 7 load balancer that enables running and scaling services behind an internal IP address.
      • also available as a cross-region internal Application Load Balancer for multi-region backends with automatic failover.
      • supports a regional backend service, which distributes HTTP and HTTPS requests to healthy backends (either instance groups containing CE VMs or NEGs containing GKE containers).
      • supports path based routing
      • preserves the Host header of the original client request and also appends two IP addresses (Client and LB) to the X-Forwarded-For header
      • supports a regional health check that periodically monitors the readiness of the backends.
      • has native support for the WebSocket protocol when using HTTP or HTTPS as the protocol to the backend
    • External Application Load Balancer (formerly External HTTP(S) Load Balancing)
      • is a global, proxy-based Layer 7 load balancer that enables running and scaling the services worldwide behind a single external IP address
      • distributes HTTP and HTTPS traffic to backends hosted on Compute Engine and GKE
      • offers global (cross-regional) and regional load balancing
      • supports content-based load balancing using URL maps
      • preserves the Host header of the original client request and also appends two IP addresses (Client and LB) to the X-Forwarded-For header
      • supports connection draining on backend services
      • has native support for the WebSocket protocol when using HTTP or HTTPS as the protocol to the backend
      • supports mutual TLS (mTLS) authentication for client certificate-based authentication.
    • Internal passthrough Network Load Balancer (formerly Internal TCP/UDP Load Balancing)
      • is a managed, internal, pass-through, regional Layer 4 load balancer that enables running and scaling services behind an internal IP address
      • distributes traffic among VM instances in the same region in a Virtual Private Cloud (VPC) network by using an internal IP address.
      • provides high-performance, pass-through Layer 4 load balancer for TCP or UDP traffic.
      • routes original connections directly from clients to the healthy backends, without any interruption.
      • does not terminate SSL traffic and SSL traffic can be terminated by the backends instead of by the load balancer
      • provides access through VPC Network Peering, Cloud VPN or Cloud Interconnect
      • supports health check that periodically monitors the readiness of the backends.
    • External passthrough Network Load Balancer (formerly External TCP/UDP Network Load Balancing)
      • is a managed, external, pass-through, regional Layer 4 load balancer that distributes TCP or UDP traffic originating from the internet to among VM instances in the same region
      • Load-balanced packets are received by backend VMs with their source IP unchanged.
      • Load-balanced connections are terminated by the backend VMs. Responses from the backend VMs go directly to the clients, not back through the load balancer (direct server return).
      • scope of a network load balancer is regional, not global. A network load balancer cannot span multiple regions. Within a single region, the load balancer services all zones.
      • supports connection tracking table and a configurable consistent hashing algorithm to determine how traffic is distributed to backend VMs.
      • supports additional protocols like UDP, ESP, GRE, ICMP, and ICMPv6.
    • External proxy Network Load Balancer (formerly External SSL Proxy and TCP Proxy Load Balancing)
      • is a reverse proxy load balancer that distributes SSL or TCP traffic coming from the internet to VM instances in the VPC network.
      • with SSL traffic, user SSL (TLS) connections are terminated at the load balancing layer, and then proxied to the closest available backend instances by using either SSL (recommended) or TCP.
      • supports global load balancing service with the Premium Tier and regional load balancing service with the Standard Tier
      • is intended for non-HTTP(S) traffic. For HTTP(S) traffic, use Application Load Balancers.
      • supports proxy protocol header to preserve the original source IP addresses of incoming connections to the load balancer

Cloud CDN

  • Cloud CDN is Google Cloud’s web acceleration solution that caches website and application content closer to the user.
  • uses Google’s global edge network to serve content closer to users, which accelerates the websites and applications.
  • works with the global external Application Load Balancer or the classic Application Load Balancer to deliver content to users
  • Cloud CDN content can be sourced from various types of backends
    • Instance groups
    • Zonal network endpoint groups (NEGs)
    • Serverless NEGs: One or more App Engine, Cloud Run, or Cloud Functions services
    • Internet NEGs, for endpoints that are outside of Google Cloud (also known as custom origins)
    • Buckets in Cloud Storage
  • supports content targeting (GA) — enables device characterization and geo-targeting for responsive websites, language customization, and currency settings.
  • Cloud CDN with Google Cloud Armor enforces security policies only for requests for dynamic content, cache misses, or other requests that are destined for the origin server. Cache hits are served even if the downstream Google Cloud Armor security policy would prevent that request from reaching the origin server.
  • recommends
    • using versioning instead of cache invalidation
    • using custom keys to improve cache hit ratio
    • cache static content
  • Media CDN
    • is Google Cloud’s media delivery solution, complementing Cloud CDN.
    • optimized for high-throughput egress workloads, such as streaming video and large file downloads.
    • uses YouTube’s infrastructure to bring video streams (VoD and live) and large file downloads closer to users.
    • supports Cloud Armor edge security policies for DDoS protection.

Cloud VPN

  • securely connects the peer network to the VPC network or two VPCs through an IPsec VPN connection.
  • encrypts the data as it travels over the internet.
  • only supports site-to-site IPsec VPN connectivity and not client-to-gateway scenarios. Cannot be used to route traffic to the public internet.
  • allows users to access private RFC1918 addresses on resources in the VPC from on-prem computers also using private RFC1918 addresses.
  • can be used with Private Google Access for on-premises hosts
  • HA VPN
    • provides a high-available and secure connection between the on-premises and the VPC network through an IPsec VPN connection in a single region
    • provides an SLA of 99.99% service availability, when configured with two interfaces and two external IP addresses.
    • supports IPv6 (dual-stack) tunnels for both inner and outer IP addresses.
    • supports customizable cipher options for VPN tunnels.
  • Classic VPN
    • provides a 99.9% SLA.
    • Classic VPN dynamic routing (BGP) was deprecated on August 1, 2025. HA VPN is now the only option for BGP connectivity in Cloud VPN. Existing tunnels continue to function but without an availability SLA. If deleted, they cannot be recreated.
    • Does not support IPv6 traffic.
  • HA VPN over Cloud Interconnect
    • allows encrypting traffic traversing Dedicated or Partner Interconnect connections.
    • deploys HA VPN tunnels over VLAN attachments for additional security and compliance.
    • Each HA VPN tunnel has a bandwidth of 3 Gbps.
  • supports up to 3Gbps per tunnel with a maximum of 8 tunnels
  • supports static as well as dynamic routing using Cloud Router
  • supports IKEv1 or IKEv2 using a shared secret

Cloud Interconnect

  • Cloud Interconnect provides options for extending the on-premises network to the VPC networks in Google Cloud.
  • Dedicated Interconnect (Dedicated connection)
    • provides a direct physical connection between the on-premises network and Google’s network
    • requires your network to physically meet Google’s network in a colocation facility with your own routing equipment
    • supports only dynamic routing
    • supports 10 Gbps, 100 Gbps, and 400 Gbps circuits.
  • Partner Interconnect (Use a service provider)
    • provides connectivity between the on-premises and VPC networks through a supported service provider.
    • supports bandwidth from 50 Mbps minimum to 50 Gbps maximum.
    • provides Layer 2 and Layer 3 connectivity
      • For Layer 2 connections, you must configure and establish a BGP session between the Cloud Routers and on-premises routers for each created VLAN attachment
      • For Layer 3 connections, the service provider establishes a BGP session between the Cloud Routers and their edge routers for each VLAN attachment.
  • Cross-Cloud Interconnect
    • provides dedicated, private connectivity between Google Cloud and another cloud provider (AWS, Azure, OCI, Alibaba Cloud).
    • offers 10 Gbps or 100 Gbps managed, encrypted links.
    • supports security options such as IPsec VPN or MACsec.
    • Partner Cross-Cloud Interconnect (for AWS) provides an on-demand method for establishing cross-cloud transport without manually setting up networking components.
  • Cross-Site Interconnect
    • is a transparent, on-demand, Layer 2 connectivity solution between on-premises network sites.
    • leverages Google’s global infrastructure for high-performance and high-bandwidth connectivity.
  • Single Interconnect connection does not offer redundancy or high availability and its recommended to
    • use 2 in the same metropolitan area (city) as the existing one, but in a different edge availability domain (metro availability zone).
    • use 4 with 2 connections in two different metropolitan areas (city), and each connection in a different edge availability domain (metro availability zone)
    • Cloud Routers are required one in each Google Cloud region
  • Cloud Interconnect does not encrypt the connection between your network and Google’s network. For additional security, use HA VPN over Cloud Interconnect or application-level encryption.

Cloud Router

  • is a fully distributed, managed service that provides dynamic routing and scales with the network traffic.
  • works with both legacy networks and VPC networks.
  • isn’t supported for Direct Peering or Carrier Peering connections.
  • helps dynamically exchange routes between the Google Cloud networks and the on-premises network.
  • peers with the on-premises VPN gateway or router to provide dynamic routing and exchanges topology information through BGP.
  • Google Cloud recommends creating two Cloud Routers in each region for a Cloud Interconnect for 99.99% availability.
  • supports following dynamic routing mode
    • Regional routing mode – provides visibility to resources only in the defined region.
    • Global routing mode – provides visibility to resources in all regions
  • is part of the Network Connectivity Center, which provides a hub-and-spoke model for managing connectivity across VPC networks, on-premises, and other clouds.

Network Connectivity Center

  • provides a hub-and-spoke model for managing network connectivity at scale.
  • enables site-to-site data transfer between on-premises locations through Google’s network.
  • supports VPC spokes, hybrid spokes (VPN/Interconnect), and router appliance spokes.
  • solves transitivity challenges through features like producer VPC spoke integration supporting Private Service Access (PSA) and Private Service Connect (PSC) propagation.
  • uses ECMP routing and BGP for route distribution between networks.

Cloud DNS

  • is a high-performance, resilient, reliable, low-latency, global DNS service that publishes the domain names to the global DNS in a cost-effective way.
  • With Shared VPC, Cloud DNS managed private zone, Cloud DNS peering zone, or Cloud DNS forwarding zone must be created in the host project
  • provides Private Zone which supports DNS services for a GCP project. VPCs in the same project can use the same name servers
  • supports DNS Forwarding for Private Zones, which overrides normal DNS resolution for the specified zones. Queries for the specified zones are forwarded to the listed forwarding targets.
  • supports DNS Peering, which allows sending requests for records that come from one zone’s namespace to another VPC network within GCP
  • supports DNS Outbound Policy, which forwards all DNS requests for a VPC network to the specified server targets. It disables internal DNS for the selected networks.
  • DNS Routing Policies
    • supports weighted round robin, geolocation, and failover routing policies.
    • can be configured with health checks for automatic failover.
    • supports internal passthrough Network Load Balancers and internal proxy Network Load Balancers as health checked targets.
  • Cloud DNS VPC Name Resolution Order
    • DNS Outbound Server Policy
    • DNS Forwarding Zone
    • DNS Peering
    • Compute Engine internal DNS
    • Public Zones
  • supports DNSSEC, a feature of DNS, that authenticates responses to domain name lookups and protects the domains from spoofing and cache poisoning attacks

Related Posts