Thanks for sharing this! Looks good so far!

Yes, creating a new provider is often best when SDKs change radically. We had to do with with GANDI_V5 (replaced GANDI), and CLOUDFLARE_API (replaced CLOUDFLARE).

One bit of feedback: Please keep names consistent. Go doesn't like hyphens or underlines in names, so let's avoid that (the Gandi and Cloudflare examples above have trouble with this reguard). Everything should be either hetzner2 or HETZNER2.

For example:

• providers/hetzner2/hetzner2Provider.go
• Code should be package hetzner2
• The internal name should be HETZNER2

Thanks for the feedback, Tom.

One bit of feedback: Please keep names consistent. Go doesn't like hyphens or underlines in names, so let's avoid that (the Gandi and Cloudflare examples above have trouble with this reguard). Everything should be either hetzner2 or HETZNER2.

I've used the same pattern as the Gandi provider: Go package gandiv5 -> hetznerv2 and user facing label GANDI_V5 -> HETZNER_V2.
Do you want to change the pattern moving forward?
If so, WDYT about aligning all the providers in the next major version of dnscontrol?

• Go gandiv5 -> gandi5 and label GANDI_V5 -> GANDI5; Alternative: Can we drop the version number now that the other provider has been removed?
• Go cloudflare -> cloudflareapi; Alternative: Can we drop the api suffix now that the other provider has been removed?
• Label AZURE_DNS -> AZUREDNS
• Go doh -> dnsoverhttps

I would be fine with making the change for hetzner2/HETZNER2 today to avoid a breaking change in the next major version for the new provider.

@das7pad Thanks for the feedback, I really appreciate it.

The result values are not "up-to-date" after waiting for an Action, e.g. Zone.AuthoritativeNameservers.Assigned is not set when Client.Zone.Create() returns and the following "wait" will not update it.

This is expected, you should fetch the zone again after the action completed, there is no way around this.

My take away is that more documentation would have been helpful to better understand how to use the SDK/API with regards to actions.

Taking a step back here: Waiting for an Action with a separate SDK call does not seem very natural to me. Does the SDK-user need to know that you are processing operations asynchronous? (Which seems like an implementation detail to me, something that the SDK could abstrct over.) Can Client.Zone.Create() return the final Zone instead of the intermediate result?

We do no want to assume how a client want to behave, waiting for actions ourselves would assume too much of the user application's behavior.

We could indeed build a layer on top, to provide the user with such convenience features, I'll take the feedback with me and see what we can do.

Performance regression due to lack of bulk create/modify. E.g. one of the test suites spends about 4.5 minutes on making creating 100 record-sets and then another 4 minutes for deleting them in sequence again. With your async API, these are create 2100 + delete 2100 = 400 API calls. Previously, these were create 1 + delete 100 = 101 API calls. Are you planning on adding batch processing again?

You can decouple calling the API and waiting for the returned actions. This should cut the waiting time by a lot. I'll add more comment about this in the PR review it self.

Let me know if after this improvement, you still think a batch processing API is needed?

Some SDK methods return an Action (e.g. Zone.ChangeRRSetTTL()), others wrap the Action in a struct (Client.Zone.CreateRRSet()) -- even when the struct has a single field (ZoneRRSetDeleteResult).

Yes, this is a pattern that we follow to prevent future breaking changes if we ever want to add a field to the Create/Delete operations.

This is expected.

I'll address more of the feedback in the pull request review.

I'm going to discuss the naming issue at the monthly video call today: #3798

• What names to use for the new HETZNER V2 provider?
  • Right now we have inconsistent naming. Do we follow the current pattern, start a new one?
    • Go styleguide discourages underlines in module names.
    • We have inconsistent names:
      • AZURE_DNS -- providers/azuredns/azureDnsProvider.go -- package azuredns
      • CLOUDFLAREAPI -- providers/cloudflare/cloudflareProvider.go -- package cloudflare
      • GANDI_V5 -- providers/gandiv5/gandi_v5Provider.go -- package gandiv5
    • Renaming providers is hard because it breaks existing configs. I’ve been considering adding “provider aliases” to make renames easier. For example, we could make CLOUDFLARE an alias for CLOUDFLAREAPI and output warnings to encourage switching to the new name.
  • Options:
    • Maintain the existing inconsistency:
      • HETZNER_V2 -- providers/hetznerv2/hetznerv2Provider.go -- package hetznerv2
    • Start a new standard: (and rename the others some day)
      • HETZNERV2 -- providers/hetznerv2/hetznerv2Provider.go -- package hetznerv2
    • Remove the "V"?
      • HETZNER2 -- providers/hetzner2/hetzner2Provider.go -- package hetzner2
    • Something else?
      • ???

I'm going to discuss the naming issue at the monthly video call today: #3798

We discussed this. We have a lot of inconsistent naming and the discussion was about whether we should try to fix the old names and what should we do with future names.

Our conclusion was:

1. Allow slugs to include underlines for readability (AZURE_DNS, HETZNER_v2), but everything else should be "downcase and remove any underlines").

• echo AZURE_DNS | tr A-Z a-z | tr -d _ outputs "azuredns"
• echo HETZNER_V2 | tr A-Z a-z | tr -d _ outputs "hetznerv2"

2. The recommendation for Hetzner:

• Slug: HETZNER_V2
• Directory/filename: providers/hetznerv2/hetznerv2Provider.go
• Package name: package hetznerv2

3. In the future, we'll make it easier to rename old providers by adding some kind of aliasing mechanism so that the old and new names work.

3. The recommendation for Hetzner:

• Slug: HETZNER_V2
• Directory/filename: providers/hetznerv2/hetznerv2Provider.go
• Package name: package hetznerv2

👍 Done in 7bcc943.

The integration tests are passing after merging main.

The code looks excellent! Only one minor comment.

Awesome, thanks for the feedback!

Some other things:

• .github/workflows/pr_integration_tests.yml: Please add HETZNERV2 to the PROVIDERS list.
• .goreleaser.yml: Search for Provider-specific changes and add hetznerv2

Done in daaba36.

@jooola Can you provide us/Tom with test credentials for running in CI?

It is no longer possible to remove your provided name servers from the root/apex. Use-case: dual-home/multi-home zone with fewer than three servers from Hetzner. I'm operating one of these and cannot migrate over until this is fixed.

But this could still work if you keep all three existing NS, and add your additional NS on top of that? Is there a problem with requiring to use all 3 existing Hetzner name servers?

My registrar used to limit the number of custom nameservers to 5. Trying this again today, it looks like that limitation no longer exists. 7 NS entries is a little excessive, but it will be fine. 😅

All the points should be addressed now. @jooola Do you want to take another look before we merge this?

@das7pad, regarding test credentials: You should be able to simply register yourself and generate the credentials on your own :) As DNS is free, you won't be charged anything.

Aside from the idna encode on the record names question, this looks good to me 🚀

(Force pushed to fix attribution with Umlaut)

@das7pad, regarding test credentials: You should be able to simply register yourself and generate the credentials on your own :) As DNS is free, you won't be charged anything.

As far as I can tell, API tokens cannot be scoped to a (free) product, here DNS. Hence I would prefer for you to provide a token.

The integration tests are passing with testing-2025-11-30-ä.dev as domain.

We are good to merge this. The credentials for CI can be provided later, preferably by Hetzner.

Thanks for contributing this!

Let's discuss the credentials via email. We have a secure way to send secrets. Contact me at tlimoncelli at stack over flow dot com for details.

Tom

Thanks for this feature! Any idea when the next release of dnscontrol will be out?

Hopefully this week. I want to merge #3879 first, then it should ship within 24 hours.

For those watching this issue and wondering if their distro ships this feature yet: It was released as part of 4.28.1: https://github.com/StackExchange/dnscontrol/releases/tag/v4.28.1

Thanks for your work here, @tlimoncelli !