DNS challenge seems to attempt to alter the wrong zone.

[louwe]

I have a free subdomain with dynu.com. I've built a Caddy server with this plugin. Caddy version is v2.8.4 h1:q3pe0wpBj1OcHFZ3n/1nl4V4bxBrYoSoab7rL9BMYNk= and it is running on a FreeBSD jail 14.0-RELEASE-p6.

Caddyfile:

*.louwe.mywire.org {
    tls {
        dns dynu {
            api_token my_token
            own_domain louwe.mywire.org
        }
    }

    @www host www.louwe.mywire.org
    handle @www {
        root * /usr/local/www/blog/public
        encode zstd gzip
        file_server
    }
}

Error:

{"level":"error","ts":1718243796.2833152,"logger":"tls.obtain","msg":"will retry","error":"[*.louwe.mywire.org] Obtain: [*.louwe.mywire.org] solving challenges: presenting for challenge: adding temporary record for zone \"mywire.org.\": dnsRecord {ID: Type:TXT Name:_acme-challenge.louwe Value:rdVQiapfZvVrc0D7jRLdAmIHYsbBQB4XK3FlBwFuLBA TTL:0s Priority:0 Weight:0}: Post \"https://api.dynu.com/v2/dns/10049633/record\": EOF (order=https://acme-v02.api.letsencrypt.org/acme/order/1398131666/277889062397) (ca=https://acme-v02.api.letsencrypt.org/directory)","attempt":1,"retrying_in":60,"elapsed":1.44899909,"max_duration":2592000}

It seems to me that it's attempting to add the TXT temporary record to the wrong zone (mywire.org) instead of (louwe.mywire.org). What am I doing wrong?

For the record, when I do this same DNS challenge flow with acme.sh script, it works flawlessly, but this is sub-optimal as I would like Caddy to manage that instead for more fool-proof integration.

[taviowong]

The zone is set by Caddy and should not be a problem because I have obtained certs successfully for my Dynu subdomain.

It seems the problem is caused by an EOF response from the Dynu API. Can you let it retry for a while and see if it is just a transient error?

[ItsIgnacioPortal]

@louwe I've found that this works for me, using the now deprecated lego package:

1. Install xcaddy: https://github.com/caddyserver/xcaddy/releases
2. Compile caddy v2.7.6. We have to use an older version because the latest versions don't work with lego-deprecated. Run: xcaddy build v2.7.6 --with github.com/caddy-dns/lego-deprecated
3. Setup your caddyfile:

   tls {
       dns lego_deprecated dynu
   }

4. Setup the environment variable DYNU_API_KEY to the API key you get from https://www.dynu.com/en-US/ControlPanel/APICredentials
5. Run caddy: caddy run

If you get authentication related errors, you may have to run caddy like this:

sudo \
DYNU_API_KEY=YOUR_API_KEY_HERE \
caddy run

[louwe]

The zone is set by Caddy and should not be a problem because I have obtained certs successfully for my Dynu subdomain.

Why would it be set by Caddy? What's the point of the own_domain parameter if it's just going to ignore it and use the one given by Caddy? Also, Caddy should be giving it the subdomain rather than the top mywire.org domain.

It seems the problem is caused by an EOF response from the Dynu API. Can you let it retry for a while and see if it is just a transient error?

I've just tried it again today and it still gives me the same error so doesn't seem to be transient.

[taviowong]

The zone is set by Caddy and should not be a problem because I have obtained certs successfully for my Dynu subdomain.

Why would it be set by Caddy? What's the point of the own_domain parameter if it's just going to ignore it and use the one given by Caddy? Also, Caddy should be giving it the subdomain rather than the top mywire.org domain.

The zone is set by Caddy using DNS lookup for SOA record for the hostname you entered. You can read more about it in my previous issue. It is beyond my control to change it so I added a field own_domain to override it internally. There's some conversion behind the scene so whatever is displayed isn't sent to dynu directly; dynu receives your subdomain as input, i.e. louwe.mywire.org, as you expected. So the displayed zone isn't causing the error you are seeing.

It seems the problem is caused by an EOF response from the Dynu API. Can you let it retry for a while and see if it is just a transient error?

I've just tried it again today and it still gives me the same error so doesn't seem to be transient.

I just created a new mywire.org subdomain and got a LetsEncrypt cert using the module so the code should still work... I'm not sure how I can help other than suggesting you let Caddy retry for a while. I do see that the lego dynu module has built-in exponential backoff retry that supposedly handles EOF errors due to the unstable API (https://github.com/go-acme/lego/blob/master/providers/dns/dynu/internal/client.go#L113). I will see if I can add this retry functionality when I have time.

If you have any error messages other than the EOF one, please post them here so I can check if there's any other problem with my code. Thanks!

[louwe]

@taviowong Is it possible that maybe the use of a wildcard subdomains may have something to do with the failures?

[taviowong]

@taviowong Is it possible that maybe the use of a wildcard subdomains may have something to do with the failures?

I am using a wildcard subdomain myself for dynu so it's not related. Would you happen to already have 4 custom DNS records as that's the limit for free accounts?

[louwe]

No, I only have 1 record. And as I said in the beginning. It works just fine with acme.sh script (currently what I'm doing).

I did at one point have more, but that also causes acme.sh to fail so it wouldn't be specific just to this plugin.

[taviowong]

I will try to port over the retry code and hope it will fix the problem for you.

[taviowong]

@louwe Can you try again with v0.1.1?