Hetzner DNS vs Google Cloud DNS: Terraform Compared
Choose Hetzner DNS when you need straightforward authoritative DNS close to Hetzner infrastructure and want to manage it through the current Cloud API and official hcloud Terraform provider. Choose Google Cloud DNS when its IAM, logging, private-zone, service-discovery, and GCP integration justify the larger platform. Reliability depends more on safe delegation and change control than on the Terraform resource syntax.
Hetzner DNS now uses the Cloud API
Old tutorials target a separate Hetzner DNS Console, token, API, and community Terraform provider. Hetzner migrated DNS management into Hetzner Console and the Cloud API. Its official migration guide documents changed authentication, API behavior, record types, limits, and features. Do not build new automation against legacy endpoints.
DNS zones and records are supported by the official Hetzner Cloud hcloud provider. Pin a tested provider version, use a narrowly scoped Cloud API token from a secret store, and review the generated plan. Migrating Terraform state from an older provider is not the same as recreating records: map resource identifiers and import state so the first apply does not delete a live zone.
Google Cloud DNS offers a broader GCP control plane
Google Cloud DNS supports public and private zones, IAM permissions, audit integration, routing policies, and DNS capabilities used by other Google Cloud services. The official product overview and current service documentation should be checked for the exact zone type. Its value is strongest when networks, identities, logs, and automation already live in GCP; using it only for a small public zone can add account and billing complexity.
Compare costs from current provider calculators using zones, monthly queries by geography, health checks or routing features, logging volume, and support. Avoid an undated “cheaper per million queries” claim. Also compare API quotas and how an outage in the main cloud account would affect emergency DNS changes. Separate DNS administration credentials from ordinary application deployment.
Design the migration to be reversible
Export the existing zone, normalize fully qualified names and trailing dots, preserve TTLs, and validate CAA, MX, TXT, SRV, wildcard, and delegated child-zone records. Lower TTLs before—not during—the move. Create the new zone, query every authoritative name server directly, then change registrar delegation. Keep the old service intact until caches have expired and monitoring confirms the new delegation.
DNSSEC needs special care. Hetzner's current documentation distinguishes support for DS records from managed signing; never publish a registrar DS record unless the authoritative zone is actually signed with the matching key. Google documents its DNSSEC workflow in the Cloud DNS DNSSEC guide. Test key rollover, API-token loss, accidental zone deletion, and break-glass access. Terraform makes DNS reproducible only when state, credentials, delegation, and recovery are protected too.
Published · Updated