hetzner: update to new API

[ldez]

Closes #2662

How to test this PR?

1. You need Go
2. Check out the PR:

   git clone https://github.com/ldez/lego.git
   cd lego
   git checkout feat/dns/hetzner-v1

3. Compile lego:
   • if you have make: make build
   • if you don't have make: go build -o dist/lego ./cmd/lego
4. Run the following command with your information (email, domain, credentials):

   HETZNER_API_TOKEN="xxx" \
   ./dist/lego --email [email protected] --dns hetzner -d '*.example.com' -d example.com  -s https://acme-staging-v02.api.letsencrypt.org/directory run

   The wildcard domain is important
5. Before each run of the command, you should clean your local environment:

   rm -rf .lego

6. Put the output of this command in a comment

[jschneider]

Oh no! I had a typo! Sorry :-(

[jschneider]

Verdict: From my point of view it seems to work.
The remaining issues seem to be timing / DNS update related.

[ldez]

I might run into the timeout?

No, if there is a timeout, an error message about that appears.

Got cleanup timeout messages, too (Wait for remove RRSet records [timeout: 1m0s, interval: 2s])

This message is not an error.
This always appears: this is the beginning of the wait for the removal of the TXT record.

---

1.1.1.1 is an example; my sentence was:

you can improve stability by adding extra resolvers (ex: --dns.resolvers 1.1.1.1).

---

Is 1.1.1.1 also used when checking for the removals?

You are mixing several things:

• the propagation check
• add/remove TXT record with the Hetzner API

Lego checks TXT record propagation after creating the TXT records and before attempting to call Let's Encrypt.

The errors DNS problem: NXDOMAIN looking up TXT for and DNS problem: server failure at resolver looking up CAA for originate from Let's Encrypt.
This happens after the propagation check by lego.

[jschneider]

Well, I don't know anything about the internals of lego ;-). Therefore, I leave it in your hands.
If I can help with further testing, give me a hint!
Until then: Thanks for your work - greatly appreciated.

[dmke]

Would it not be better to just use the API key here (and maybe log a strongly worded warning about the API token)?

I could imagine a scenario where one would rollout both the API token and API key, and then gradually upgrade the lego binaries (or more likely their traefik instances).

[dmke]

(Otherwise: LGTM)

[ldez]

I think about when I added the message.

For me, APIToken should "override" APIKey.

NewDNSProvider() and NewDNSProviderConfig(*Config) should have the same behavior.

NewDNSProviderConfig() when there is no env var should report the same error as hetznerv1, I should duplicate the code, and I was not happy with that.

But duplication, in this context, is not important.

[ldez]

🤔 You are thinking the opposite of me:

• you: APIKey > APIToken
• me: APIToken > APIKey

If you are using a previous version of lego, you can set APIKey and APIToken without any problem because only APIKey will be handled.

APIToken is related to v1, and APIKey is related to legacy.

For me, it's better to use APIToken even if APIKey is defined.