search

publishlab / node-acme-client

Simple and unopinionated ACME client for Node.js
MIT License
266 stars 52 forks source link

Authorization not found in DNS TXT records #51

Closed bstabens closed 2 years ago

bstabens commented 3 years ago

"Error: Authorization not found in DNS TXT records for test.managed-test.de"

When I do a dig _acme-challenge.test.managed-test.de @mydnsserver TXT I get the correct TXT record. I've read the documentation about debugging, but since I'm doing this on a node-red installation I'm totally not sure what I'm supposed to do where. Any help very much appreciated.

mikecabana commented 3 years ago

Ran into the same issue. Did you get anywhere @bstabens ?

bstabens commented 3 years ago

Hi Mike, no, not a bit, and no reaction from the maintainer yet.

nmorsman commented 3 years ago

Hi,

What you're experiencing is the internal challenge verification timing out without a valid DNS response. This can be caused by several things, for example slow updates from the DNS provider or something stuck in cache.

When checking manually with dig, are you using the same DNS-server as the node-red installation? Also what TTL are you using when responding to the challenge on the _acme-challenge.example.com record?

You can try increasing the amount of time the client will wait for a valid response before throwing errors by using the backoff*-options in the constructor[1]. You can also try disabling the internal challenge verification altogether[2].

I'm not familiar with node-red, but debugging can be enabled by setting the environment variable DEBUG=acme-client.

[1] https://github.com/publishlab/node-acme-client/blob/master/docs/client.md#new-acmeclientopts [2] https://github.com/publishlab/node-acme-client#internal-challenge-verification

bstabens commented 3 years ago

Hi nmorsman, this is my own DNS server that's used by the node red, too. I'm not sure at the moment about the TTL but will have a look into it. I already disabled the internal challenge and hopped to completing the challenge for further testing, but also no luck. Where do you want me to set the DEBUG? At the docker container shell where my nodered lives, in the settings.js, in the external-modules file path?

jbuhacoff commented 2 years ago

Both suggestions from @nmorsman worked for me. Setting the DEBUG=acme-client variable exposed the issue, and customizing backoffAttempts, backoffMin, and backoffMax options solved it.

kebetsi commented 2 years ago

Hi all,

I believe that the issue comes from the fact that during the verification phase, the DNS requests are not made against the name servers of the domain. Therefore, it is getting cached DNS responses from prior attempts.

This might be fixed if we:

  1. Find the name servers
  2. Set them as Resolvers for the DNS client
  3. Use this resolver for the CNAME and TXT resolution.
kebetsi commented 2 years ago

Example implementation: https://github.com/publishlab/node-acme-client/pull/55

nmorsman commented 2 years ago

Hey all and thanks for your input and debugging on this.

Version 4.2.0 comes with many improvements to verifying dns-01 challenges. First off a small improvement in a7f9748cc6df7a052d125a07c34ed5a93a5000eb where the default backoffAttempts has been increased to 10 so that it will keep trying a bit longer before giving up out of the box.

In addition to this the use of authoritative name servers has been implemented for TXT and CNAME lookups in b0fcfeb67c258bf15b30211561e2e72825e6d3ed and 5b2153c89aaf13c98fa05cb47a30b9a3e0a33ea8. Thanks for locating this issue and drafting a PR for the solution @kebetsi. The internal steps for verifying dns-01 challenges are now as follows:

  1. Lookup CNAME using the default DNS resolver, if found = restart lookup using CNAME value
  2. Lookup TXT using the default DNS resolver, if found = return values
  3. Attempt to resolve the domain name and authoritative name servers
  4. Lookup CNAME using authoritative NS, if found = restart lookup using CNAME value
  5. Lookup TXT using authoritative NS, if found = return values

The reason we need to attempt with the default resolver as well is that the TXT answer can be delegated to another name server, which will not resolve correctly using only the authoritative NS, for example:

ns01.example.com (authoritative)
_acme-challenge.example.com 3600 IN NS ns01.delegate.com.

ns01.delegate.com (delegate)
_acme-challenge.example.com 300 IN TXT "dns-01 answer"
nmorsman commented 2 years ago

Improvements to dns-01 verification published with v4.2.0! Please let me know if you have any further issues related to this.

wmantly commented 1 month ago

@nmorsman Thank you for the good work!

I have recently run into an issue (I admit I would have saved myself some time if I fully read the readme...) where my DNS verification was failing and I could not figure out why. It would be great for idiots like me who don't RTFM if the error messages in src/verify.js stated that the local system failed to verify and not the remote ACME provider as one would assume. I would go ahead and make a PR to correct this, but would like your input on the matter first.

The issue I ran into: https://community.letsencrypt.org/t/dns-01-validation-fails/223062

Thank you, @wmantly