Skip to main content
provisioning · GCP

Cloud DNS

category
DNS
cloud
GCP

What does ZopDay create for Cloud DNS?

ZopDay creates a public Cloud DNS zone when you pick a domain for a GKE cluster. A cluster called shop with the domain example.com gets shop-zone for shop.example.com. A wildcard A record with a 300-second TTL is added only if ingress-nginx already has an address, which a new cluster does not. ZopDay adds no delegation, CAA records or IAM grants.

Cloud DNS is Google Cloud’s managed DNS service. ZopDay uses it in two places: a managed zone it creates for a GKE cluster when you pick a domain, and records it writes into an existing zone when you attach a domain to a space.

How does ZopDay create a managed zone for a GKE cluster’s domain

The cluster’s Advanced settings on the Provision screen have an optional Domain field. It lists the Cloud DNS zones discovered in the project, plus None. When you pick one, the cluster job gets an extra DNS step that runs once the cluster is ready. That step creates a managed zone in the connected project. ZopDay does not set the zone’s visibility, so Cloud DNS makes it public. The example below is for a cluster called shop and the domain example.com.

Terminal window
Input: domain (a discovered zone, or None)
Zone name: the cluster name plus -zone, such as shop-zone (dots in the cluster name become dashes)
DNS name: the cluster name plus the domain, with a trailing dot, such as shop.example.com.
Description: Managed by zop-provisioner for shop
Record: *.shop.example.com A to the ingress-nginx load balancer IP, TTL 300, only if that IP exists

The zone carries ZopDay’s labels for the cluster, so you can find it by label as well as by name.

Why is the GKE wildcard record usually missing

The DNS step reads the external address of the ingress-nginx-controller Service in the ingress-nginx namespace. It runs before ZopDay installs the cluster’s add-ons. At cluster creation nothing is installed unless you picked it in the wizard. So on a new cluster that Service does not exist yet, and the zone is created with only its NS and SOA records. ZopDay does not come back to add the record. ingress-nginx arrives later, from your wizard picks or from the baseline ZopDay installs before the first deploy. Add the wildcard record yourself, or attach the domain to the space as described below.

Who sets up delegation, CAA records and IAM for the GKE zone

You do. ZopDay writes no NS records into the parent zone. Names in the new zone do not resolve publicly until you add its name servers at the parent zone or registrar. That holds even when the parent zone is in the same project. ZopDay adds no CAA records. It grants no IAM roles on the zone either: access follows the IAM your project already has.

What happens to a GKE cluster when Cloud DNS fails

If zone creation fails, the DNS step is marked skipped and the cluster finishes without DNS. A retried job does not recreate a zone it has already recorded. EKS and AKS clusters get their own zones in Route 53 and Azure DNS. This zone is not shared across clouds.

How does attaching a domain write Cloud DNS records

Separately, a space’s Domains tab lets you pick a cloud account, one of its existing Cloud DNS zones and a hostname. ZopDay then writes the record into that zone in one atomic change: an A record when the target is an IP address, a CNAME when it is a hostname, with a 300-second TTL. For a cluster space the target is the ingress-nginx load balancer, looked up live, so ingress-nginx must be installed first. The tab shows Pending DNS, Verified or Failed. Detaching the domain deletes the record.

Which Cloud DNS records go when the cluster is deleted

Deleting the cluster job deletes the GKE cluster first. Then it deletes every record in the zone except NS and SOA, and then the zone itself. Records you added by hand are deleted with it. Keep anything that must outlive the cluster in a zone ZopDay did not create.

Provision Cloud DNS from ZopDay in your own cloud account, or read how the provisioner works first.

See it fire on your bill.

Connect an account read-only in about five minutes. Findings start with the first scan.

472 rule families across 353 resource types on 22 platforms. Every threshold, metric, and IAM action is documented on these pages before you grant anything.

472 rule families documented
353 resource types covered
read-only default access level
Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console·