Failing 'cause doing direct DNS instead of using system resolvers

[hvisage]

System inside a protected environment where only proxied HTTPS is allowed to specific sites (like LetsEncrypt) Only single DNS resolver allowed (firewall)

It seems it tries to do a direct DNS lookup against the acmedns.io servers, instead via the system resolvers, even when "forced" in the config file, and thus times out without continuing ;(

2022/04/18 20:45:06.066 INFO    tls.obtain      lock acquired   {"identifier": "sa.see.trosint.ovh"}
2022/04/18 20:45:06.068 INFO    tls.issuance.acme       waiting on internal rate limiter        {"identifiers": ["sa.see.trosint.ovh"], "ca": "https://acme-v02.api.letsencrypt.org/directory", "account": ""}
2022/04/18 20:45:06.068 INFO    tls.issuance.acme       done waiting on internal rate limiter   {"identifiers": ["sa.see.trosint.ovh"], "ca": "https://acme-v02.api.letsencrypt.org/directory", "account": ""}
2022/04/18 20:45:07.057 INFO    tls.issuance.acme.acme_client   trying to solve challenge       {"identifier": "sa.see.trosint.ovh", "challenge_type": "dns-01", "ca": "https://acme-v02.api.letsencrypt.org/directory"}
2022/04/18 20:45:30.954 ERROR   tls.obtain      could not get certificate from issuer   {"identifier": "sa.see.trosint.ovh", "issuer": "acme-v02.api.letsencrypt.org-directory", "error": "[sa.see.trosint.ovh] solving challenges: waiting for solver certmagic.solverWrapper to be ready: checking DNS propagation of _acme-challenge.sa.see.trosint.ovh: dial tcp 46.4.128.227:53: i/o timeout (order=https://acme-v02.api.letsencrypt.org/acme/order/503426720/81299293330) (ca=https://acme-v02.api.letsencrypt.org/directory)"}
2022/04/18 20:45:30.954 WARN    tls.issuance.zerossl    missing email address for ZeroSSL; it is strongly recommended to set one for next time
2022/04/18 20:45:31.608 INFO    tls.issuance.zerossl    generated EAB credentials       {"key_id": "tlyiJFmhVibRtrDS0XzGTw"}
2022/04/18 20:45:37.579 INFO    tls.issuance.acme       waiting on internal rate limiter        {"identifiers": ["sa.see.trosint.ovh"], "ca": "https://acme.zerossl.com/v2/DV90", "account": ""}
2022/04/18 20:45:37.579 INFO    tls.issuance.acme       done waiting on internal rate limiter   {"identifiers": ["sa.see.trosint.ovh"], "ca": "https://acme.zerossl.com/v2/DV90", "account": ""}
2022/04/18 20:45:41.470 INFO    tls.issuance.acme.acme_client   trying to solve challenge       {"identifier": "sa.see.trosint.ovh", "challenge_type": "dns-01", "ca": "https://acme.zerossl.com/v2/DV90"}
2022/04/18 20:46:06.003 ERROR   tls.obtain      could not get certificate from issuer   {"identifier": "sa.see.trosint.ovh", "issuer": "acme.zerossl.com-v2-DV90", "error": "[sa.see.trosint.ovh] solving challenges: waiting for solver certmagic.solverWrapper to be ready: checking DNS propagation of _acme-challenge.sa.see.trosint.ovh: dial tcp 46.4.128.227:53: i/o timeout (order=https://acme.zerossl.com/v2/DV90/order/luQ-OiZrMRP-xipKe_WcCQ) (ca=https://acme.zerossl.com/v2/DV90)"}
2022/04/18 20:46:06.003 ERROR   tls.obtain      will retry      {"error": "[sa.see.trosint.ovh] Obtain: [sa.see.trosint.ovh] solving challenges: waiting for solver certmagic.solverWrapper to be ready: checking DNS propagation of _acme-challenge.sa.see.trosint.ovh: dial tcp 46.4.128.227:53: i/o timeout (order=https://acme.zerossl.com/v2/DV90/order/luQ-OiZrMRP-xipKe_WcCQ) (ca=https://acme.zerossl.com/v2/DV90)", "attempt": 1, "retrying_in": 60, "elapsed": 59.93731711, "max_duration": 2592000}

Caddyfile:

{
acme_dns acmedns /etc/acmedns/clientstorage.json
}

sa.see.trosint.ovh {
tls {
 resolvers 10.128.20.1
dns acmedns /etc/acmedns/clientstorage.json
}
        reverse_proxy http://a.see.trosint.ovh:9000
}

[mholt]

Thanks for the question! (FYI we are also tracking this same question in the forums: https://caddy.community/t/forcing-certmagic-to-use-system-resolvers-for-propagation-checks/15690?u=matt)

[vbsd]

As noted in the Caddy forum thread, DNS propagation check is done by certmagic. Any option to resolve records differently or even to disable the propagation check would have to be implemented there, this plugin doesn't have that kind of control. Closing the issue.

[hvisage]

As noted in the Caddy forum thread, DNS propagation check is done by certmagic. Any option to resolve records differently or even to disable the propagation check would have to be implemented there, this plugin doesn't have that kind of control. Closing the issue.

Which is contradicting the Caddy/Certmagic forum statement ;(

https://caddy.community/t/forcing-certmagic-to-use-system-resolvers-for-propagation-checks/15690/6 That’s not for Caddy/Certmagic to control, I think, it’s up to the acmedns plugin to control how that’s resolved.

[vbsd]

My responses are here and here. I still don't think this is something that can or should be fixed with the plugin. But I'll keep an eye on the discussion.