Consider lowering the default value of `acmeTxtRecordTTL` to 60 seconds

[mardonner]

Is your feature request related to a problem? Please describe.

Hi, I have this issue in my ske cluster where I consistenly run into issues when wanting to create certificates with our pki (pki.schwarz) (which i have no control over) when using the DNS challenge.

After a certain amount of time (around 4-5 Minutes) my challenges are invalidated. On certs with multiple dns names (e.g. wildcard certs), the first challenge is validated while the second one fails after a while. Especially, since I also try to create multiple certificates for the same domain for two different ingress controllers in two different namespaces (for testing and debugging).

Lowering acmeTxtRecordTTL to 60 in my issuer manifest improves the situation significantly, although not guaranteed.
I think this is due to DNS caching issues on either the cluster side (coredns) or the CA side.

One thing that somewhat contributes to this issue is that this webhook queues dns txt records sequentially (pr #166) instead of using parallel multi txt records (admittedly, according to my llm).

I can't tell if this issue is a quirk of my pki or the webhook.

my env:
SKE Kubernetes Version: 1.35.6 (flatcar 4593.2.2)
Webhook Version: 0.4.11
cert-manager version: 1.21.1

Describe the solution you'd like

Lower this value to 60:

stackit-cert-manager-webhook/internal/resolver/config.go

Line 85 in f323016

cfg.AcmeTxtRecordTTL = 600

I admit, I don't know the reasoning for 600. There might be a good reason for this, so please enlighten me :)
With let's encrypt I don't have these issues.

OR implement parallel multi TXT record support.
letsencrypt docs:

You can have multiple TXT records in place for the same name. For instance, this might happen if you are validating a challenge for a wildcard and a non-wildcard certificate at the same time.

Resource Record Set (RRset) are the mechanism here (according to my llm).

Describe alternatives you've considered

I also experimented with cert-manager's options.

Setting dns01RecursiveNameserversOnly: true in the values file significantly worsened the situation. The challenges were invalidated and took forever to complete (30 min+).

I did this in combination with:

dns01RecursiveNameservers: "1.1.1.1:53,8.8.8.8:53"
# also tried
dns01RecursiveNameservers: "<two of our internal dns servers>"

Also tried these with dns01RecursiveNameserversOnly: false but it did not change the situation much.

The other obvious alternative would be to define it in the issuer manifest.

# ...
    solvers:
    - dns01:
        webhook:
          solverName: stackit
          groupName: acme.stackit.de
          config:
            # ...
            acmeTxtRecordTTL: 60

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

Any comments or opinions on this?