Cloud DNS
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.
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 shopRecord: *.shop.example.com A to the ingress-nginx load balancer IP, TTL 300, only if that IP existsThe 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.