Hetzner DNS Console is gone: moving your zones and tokens to the Hetzner Console

The DNS service did not disappear with dns.hetzner.com. Its control plane moved into console.hetzner.com and the Hetzner Cloud API. If DNS still resolves but certificate renewal, dynamic DNS, or Kubernetes automation fails, inspect the integration and credential before changing the zone itself.

Hetzner DNS Console migration timeline#

Hetzner’s dates changed from an initial plan to a final shutdown schedule. The October 7, 2025 announcement said the beta was expected to end on November 10, recommended manual migration by the end of April 2026, and planned an early-May shutdown. Hetzner’s final migration FAQ and status notice refined that schedule:

An official Hetzner Community update from August 2026 confirms the outcome: the old console and legacy API shut down in May, and remaining zones were migrated automatically.

There were two different statements at different stages, and both were true at the time. The manual migration instructions originally said no zones were migrated automatically; you had to trigger a one-way move. The final schedule later added an automatic migration for whatever remained before the old system became read-only. If you moved early, you controlled the timing. If you did not, Hetzner completed it before shutdown.

What moved automatically, and what stayed the same#

The migration moved the zone’s control-plane representation, not its delegation to a new DNS network. Hetzner’s migration documentation said resolution had no downtime, zone settings remained unchanged, and both consoles used the same authoritative nameservers. During a manual move the zone was briefly locked against changes, disappeared from the old console when complete, and appeared under a project named DNS Migrated. You could then transfer it to another project.

The final automatic pass moved all remaining zones. Hetzner’s current DNS overview still distinguishes three valid assigned nameserver sets and notes that older primary zones can keep the older set. Do not replace nameservers merely because a blog example shows a newer set.

What did not carry over was access to the old API. Tokens issued at dns.hetzner.com, scripts using its request headers, and tools built only for its record endpoints cannot authenticate to the Cloud API. The current features and integrations page states this directly: you need a new token from the Hetzner Console, and old DNS Console tokens do not work.

Hetzner DNS API changes that break old clients#

The new API is not a version bump at the old hostname. It changes the endpoint, credential scope, and update model.

The RRSet change is easy to miss. All values with the same name and type form one set and share a TTL. A script that used to find one record ID and patch one value must now read the RRSet, retain values it still wants, and submit the complete desired set. Hetzner’s old migration validator required equal TTLs for records with the same name and type for exactly this reason.

The current API’s shape is documented under zones and RRSets. Hetzner’s updated DDNS tutorial demonstrates the practical sequence: resolve the zone through /zones?name=..., fetch /zones/{id}/rrsets, find the exact A or AAAA RRSet, and call set_records.

Create a new Hetzner DNS API token#

A Hetzner DNS API token now means a Hetzner Cloud API token for the project containing the zone. Open that project, then use Security → API tokens → Generate API token. Choose Read for inventory or a source-only preview and Read & Write for an integration that creates or changes records. Hetzner displays the token once.

A token from the wrong project can authenticate successfully while returning no expected zones. Separate projects are therefore useful for least privilege, but every consumer must use a token from the project that owns its zone. Hetzner’s token guide documents the permissions and Bearer header; the DNSMigrator Hetzner setup page gives the exact connection steps.

Do not put Bearer into a credential field unless the client asks for a complete header. DNSMigrator accepts the token secret itself and adds the header. It uses the Hetzner Console Cloud API at https://api.hetzner.cloud/v1, reads primary-zone RRSets, and refuses secondary-mode zones because the release adapter does not read or write their records.

Which integrations broke after the Hetzner DNS API changes?#

Any integration still calling dns.hetzner.com/api/v1 or presenting an old token stopped writing after May 20. Hetzner warned that plugins could unexpectedly stop in May and published a replacement list. “Supported” in that list means a compatible release exists; it does not update your deployment or secret automatically.

For certificate automation, test an issuance or staging renewal now. Waiting for the next production renewal window turns an API migration problem into an expiring-certificate incident. For external-dns, reconcile a harmless test record and confirm the controller no longer logs 401, 403, 404, or legacy-host errors.

How to verify your zones after the move#

First open the zone in Hetzner Console and read its Name servers tab. New primary zones normally use:

hydrogen.ns.hetzner.com.
oxygen.ns.hetzner.com.
helium.ns.hetzner.de.

Older migrated primary zones may still use:

ns1.first-ns.de.
robotns2.second-ns.de.
robotns3.second-ns.com.

A konsoleH-linked zone can have a third documented set. Use the assigned set shown for your zone; do not mix sets. Query every assigned authority directly with recursion disabled:

dig +norecurse @hydrogen.ns.hetzner.com example.com SOA
dig +norecurse @hydrogen.ns.hetzner.com example.com A
dig +norecurse @oxygen.ns.hetzner.com example.com MX
dig +norecurse @helium.ns.hetzner.de example.com TXT

Expect the aa flag and the intended complete RRSet. Repeat representative queries against all three servers, including AAAA, CAA, SRV, DKIM selectors, _dmarc, _acme-challenge, wildcards, and a name that should not exist. Then inspect the published delegation:

dig +short example.com NS
dig +trace example.com NS

The parent delegation should match the assigned Hetzner set. Hetzner’s delegation guide says nameserver changes can take up to 48 hours, but a console migration that retained the same set should not start a new delegation change. Use the propagation checker only after confirming the authorities themselves are correct.

Finally, exercise every writer: DDNS, ACME DNS-01, external-dns, cert-manager, Terraform, DNSControl, or a custom deployment. DNS answers prove the current zone is serving; they do not prove a token can make the next change.

Move from Hetzner DNS if you prefer another provider#

The console migration does not require you to remain with Hetzner. Create a project-scoped Read token, connect a primary Hetzner zone as the source, and choose any supported destination. DNSMigrator reads that zone’s Cloud API RRSets, normalizes them, and compares them with the destination’s capabilities.

Review every status in the migration preview, especially provider-specific record types and TTL changes. Apply to the destination and verify its authoritative nameservers before changing the registrar. Hetzner’s current catalog has no automatic DNSSEC signing, so the destination’s DNSSEC capabilities and any parent DS state need a separate check. Follow the nameserver cutover guide, keep Hetzner answering through the old delegation TTL, and use the DNS migration checker to confirm the live result.

If you want a portable backup first, export the normalized zone through the BIND zone-file workflow. A file is useful for records, but it will not carry project permissions or repair old integrations; migrate those consumers deliberately.