search

go-acme / lego

Let's Encrypt/ACME client and library written in Go
https://go-acme.github.io/lego/
MIT License
7.95k stars 1.02k forks source link

Need option to disable recursive NS checks #904

Closed pdumais closed 5 years ago

pdumais commented 5 years ago

Hi,

When behind a corporate proxy that will not allow traffic to go out to public DNS servers, it is not possible to have the recursive DNS check working.

I could use --dns.disable-cp but then that won't guarantee any propagation. It would be nice to have an option that doesn't check recursively and would only validate the challenge on the selected DNS server.

ldez commented 5 years ago

To validate the challenge, LE need to get the TXT record from the DNS server, then the propagation check is very important to avoid rate limit issue (due to failed requests).

We do a propagation check before asking to LE to try to solve the challenge.

I could use --dns.disable-cp but then that won't guarantee any propagation. It would be nice to have an option that doesn't check recursively and would only validate the challenge on the selected DNS server.

--dns.disable-cp is the option to do that :wink:

pdumais commented 5 years ago

oh ok. I was under the impression that this option would disable the check completely. But if I use that, then it fails with "DNS problem: NXDOMAIN looking up TXT for _acme-challenge....". Why isn't it retrying until propagation to my server is done? I'm using gandiv5

ldez commented 5 years ago

To be precise, --dns.disable-cp disable the need of a complete propagation (i.e. the need to find the TXT record on "all" NS) but it still requires that at least one NS has the record.

Try to perform a challenge without any DNS propagation check is a trap because more than 99% of the challenges will fail.

You can restrict the NS by setting a custom /etc/resolv.conf or a custom --dns.resolvers.

pdumais commented 5 years ago

Hi, Thanks for the fast replies.

I guess I don't fully understand the propagation mechanism because I was assuming that if the entry exists on the server defined in --dns.resolvers (our corp dns forwarding/caching server), then it necessarly means that it exists on all upstream forwarding servers. Right? So no need to check on those.

What I am confused about is that if I use --dns.disable-ct, after the first failure (because the corp forwarder is not aware of the updated challenge or because it would return nxdomain), then there is no re-attempt to query the server and the app simply fails.