Google Cloud DNS

From Luis Gallego Hurtado - Not Another IT guy
Jump to: navigation, search

A DNS is a hierarchical distributed database that lets you store IP addresses and other data, and look them up by name.

Google Cloud DNS lets you publish your zones and records in the DNS without the burden of managing your own DNS servers and software.


  • 100% uptime, highly scalable.
  • It offers both, public and private managed DNS zones.
  • It supports DNS forwarding.
  • Cost effective.


  • Project
  • Managed zones
  • Resource Record Set collection
  • Resource Record changes. Changes apply when record expires according to TTL (Time To Live).

Public DNS Zones

A public zone is visible to the Internet.

Cloud DNS has public authoritative name servers that respond to queries about public zones regardless of where the queries originate.

You can create DNS records in a public zone to publish your service on the Internet.

Cloud DNS assigns a set of name servers when a public zone is created.

DNS Name - Type - TTL (seconds) - Data : - A - 300 - [public_ip_address] Public zones do support DNS security extensions (DNSSEC) which can be specified to on, off or transfer.

Private DNS Zones

A private zone is visible only from one or more VPC networks that you specify.

Private zones enable you to manage custom domain names for your virtual machines, load balancers, and other GCP resources without exposing the underlying DNS data to the public Internet. A private zone can only be queried by resources in the same project where it is defined.

GCP creates internal DNS names for VMs automatically, even if you do not use Cloud DNS:

  • Each instance has hostname that can be resolved to an internal IP address. Hostname is the same as the instance name and fully qualified domain name (FQDN) is hostname.c.project-id.internal.
  • Name resolutions are handled by internal DNS resolver, provided as part of compute engine, and configured for use on instance via DHCP.

Private zones do not support DNS security extensions (DNSSEC).

DNS Forwarding

You can set up DNS forwarding between your non-GCP name servers and GCP's internal name servers.

Configuring bi-directional DNS forwarding allows instances in your VPC network to look up the addresses of hosts in your on-premises or multi-cloud networks.

This allows hosts on linked networks to look up addresses for resources in your VPC network.

A DNS server policy allows you to configure inbound and outbound DNS forwarding for a VPC network. You can apply one DNS server policy to a given VPC network.

Inbound DNS Forwarding

Each VPC network provides DNS name resolution services to the VM instances that use it.

By default, the VPC network's name resolution services are not available outside of that network.

You can make them available to systems in on-premises networks connected using Cloud VPN or Cloud Interconnect by creating a DNS policy to enable inbound DNS forwarding to the VPC network.

When a DNS policy is configured, GCP allocates an internal IP address in a subnet (in a region) of your VPC network to serve as a proxy for inbound DNS requests.

Outbound DNS Forwarding

You can configure a DNS policy for outbound forwarding by specifying a alternative name servers with internal IP addresses of other GCP VMs in your VPC network or systems.

You can also specify alternative name servers using public IP addresses, which must be accessible on the Internet.

You can also setup outbound DNS forwarding through the definition of a forwarding zone All matching queries for a forwarding zone are forwarded to a set of destination DNS servers.

Split Horizon DNS

A split horizon DNS is a private zone with a different set of DNS records, specific to your VPC network. It is a combination of public and private zones.

Split horizon DNS is useful if you have separate development, corporate, and production VPC networks:

  • You can define a private zone and authorize access from a development VPC network so that queries from VMs in that network for DNS records in that zone are directed to other VMs in the same network.
  • You can define a second private zone serving the same DNS records with different answers, authorizing access from a corporate network.
  • You can define a third, public zone serving the same DNS records with appropriate public answers suitable for production.


  • Fee based on number of queries.
  • Fee based on number of managed zones.