-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lego tries to read non-CNAMED record with LEGO_EXPERIMENTAL_CNAME_SUPPORT enabled #1739
Comments
Hello, since 4.9.0, the But currently, some providers don't support it, I created a PR to fix some of them #1735
|
I think you are using desec, this provider is already working with CNAME. To find the "real" domain, lego will perform recursively CNAME calls. |
Hi,
This is done via DNS not via the API, right? To summarize:
but since the error message says that lego tried to access The CNAME |
Yes it's only DNS calls
It's not possible with lego: lego always uses the same domain. Some error messages use the "original" domain but the "original" domain is never used with the desec API or the ACME API. |
to summarize the algo:
When we have to "real" domain, we use it to perform API calls to DeSec and ACME servers. In the following error message:
If lego use that domain it's only related to DNS calls (not API calls), so my bet is on your DNS (local or remote) or on a network issue that impacts DNS calls. |
The basic algorithm didn't really change, we just added a recursivity on CNAME calls. Since the 4.9.0, we improved this part (the recursivity), and when the PR will be merged I will create a v4.9.1. |
Thanks for your reply. To avoid confusion around the "real" and "original" wording:
To better diagnose these issues it would be nice if lego were to log these steps and the DNS answers it got, that would allow for direct confirmation of your suspicion. So we will wait for a more verbose output and see what the log says this happens next time. |
This comment was marked as off-topic.
This comment was marked as off-topic.
a quick recap:
(the used script is included in full in the first comment of this issue) example with errorThe following example shows the output of a failed renewal attempt, the used script is pasted in full in the first comment of this issue.
working example a few moments laterEspecially note Found CNAME entry for..
Would it be possible to add some log output that shows the CNAME DNS check result to confirm that this is a transient DNS failure or is this already planed as part of #1039? |
If you don't have "Found CNAME entry ..." log, it's because of one of the following cases:
So for me, as you have:
the problem is related to your DNS. Adding logs will not provide something more precise than what you already have. |
Thanks for your prompt reply!
I see your point there, the only difference is that it would also be clear to the user that the absence of a specific log line means X without requiring to ask you, the developer, especially if they do not have access to a good log sample. |
Welcome
What did you expect to see?
Lego should be able to renew the certificate without errors and without trying to get the non-CNAMED target via the DNS provider API.
The hostname for the certificate is
bender-doh.applied-privacy.net
(and others).There is a CNAME for that host points to:
_acme-challenge.bender-doh.applied-privacy.net. -> bender-doh.acme-dns-challenge.applied-privacy.net.
The DNS API token is authorized to read and write under acme-dns-challenge.applied-privacy.net.
but NOT under bender-doh.applied-privacy.net.
This setup worked for a long time (>1y), but now we got the following error:
which implies that lego attempts to read _acme-challenge.bender-doh.applied-privacy.net via the DNS provider API, but is not authorized to do so.
If we run lego multiple times (with the same script) it works sometimes.
What did you see instead?
error:
How do you use lego?
Binary
Reproduction steps
Unfortunately we have no clear reproducer as it works sometimes and sometimes it results in the error mentioned above.
Version of lego
lego version 4.9.0 freebsd/amd64
Logs
Go environment (if applicable)
No response
The text was updated successfully, but these errors were encountered: